Make NUnit tests runnable in VS Test Explorer

[stakx]

While the test projects can simply be started to run the tests (thanks to NUnitLite), tests cannot be run in VS Test Explorer, which could be handy especially when one wants to run only a subset of all tests.
Currently, doing that requires one to set a --test=... command-line argument in the test project settings.)

This commit adds the packages required to run our tests in VS Test Explorer.

[stakx]

Agh! I had everything working fine, then updated Visual Studio to 16.2.0, and now tests once again no longer run. I'll investigate. It'll likely be due to this test run error (there are a few of those):

An exception occurred while invoking executor 'executor://nunit3testexecutor/': Incorrect format for TestCaseFilter Error: Invalid Condition 'FullyQualifiedName=Castle.DynamicProxy.Tests.CustomAttributeInfoTestCase.FromExpression_Creates_Same_CustomAttributeInfo_As_Calling_The_Constructor => new MyAttribute1 {IntProperty = 42, StringProperty = "foo", ArrayProperty = new [] {1, 2, 3}},Castle.DynamicProxy.CustomAttributeInfo'. Specify the correct format and try again. Note that the incorrect format can lead to no test getting executed.

[stakx]

Found the problem, reported it on Microsoft Developer Community, and added a workaround to prevent test run failure.

I know we're uglifying a unit test here (hopefully only for the time being), however I think it's worth the price if it allows us to pick and run tests straight from Visual Studio.

[jonorossi]

Interesting to see Microsoft.NET.Test.Sdk is versioned 16.2.0. Is this a package just for Visual Studio with a name making it sound like it is for all .NET CLI unit testing.

[stakx]

AFAIK, the package version isn't directly tied to a particular version of VS. But I have never been too clear what exactly requires this package... maybe VS, maybe VSTest. I might run some experiments to find out. Will report back my findings if & when I do so.

[stakx]

@jonorossi, while I don't understand the whole theory behind that package, it indeed enables dotnet test! In fact, we can use all of dotnet restore|build|test now, if we make one further addition in common.props that looks roughly like the following (as per dotnet/msbuild#1333 (comment)):

<PropertyGroup>
  <FrameworkPathOverride Condition="'$(TargetFramework)|$(OS)' == 'net35|Windows_NT'">$(MSBuildProgramFiles32)\Reference Assemblies\Microsoft\Framework\.NETFramework\v3.5\Profile\Client</FrameworkPathOverride>
  <FrameworkPathOverride Condition="'$(TargetFramework)|$(OS)' == 'net35|Unix'">$(MONO_DIR)/../lib/mono/2.0-api</FrameworkPathOverride>
</PropertyGroup>

(We already do something similar in build.sh for .NET 4.6.1 compilation on Mono.)

I've only verified dotnet tooling for Windows, the Mono/Linux override will need some more work. But essentially, the MONO_DIR variable can be set on the shell using export MONO_DIR=$(dirname $(which mono)), then passed in to the MSBuild projects.

[jonorossi]

I know we're uglifying a unit test here (hopefully only for the time being), however I think it's worth the price if it allows us to pick and run tests straight from Visual Studio.

Agreed. I was expecting something much uglier 😉.