diff options
author | Sven Boemer <sbomer@gmail.com> | 2019-03-26 23:05:14 +0300 |
---|---|---|
committer | Marek Safar <marek.safar@gmail.com> | 2019-03-26 23:05:14 +0300 |
commit | 5175506202f74bdfaa35e08aa5d91e04b4fed7f2 (patch) | |
tree | e2fb699b8e33269633215a0bc221e2a9bdfb8146 /global.json | |
parent | f23fb32406f45aeb70e1b835d5c95bb4837f4da1 (diff) |
Enable unit tests on .NET Core (#489)
This enables the unit tests to run on .NET Core. CodeDom compilation doesn't exist on core, so I've added the ability to compile in-process with Roslyn APIs. This still uses NUnit, using a recent version of NUnit package references with "dotnet test". This doesn't change how tests run on mono.
Finding the right reference assemblies for compilation is a bit different on .NET Core. As described in https://github.com/dotnet/roslyn/wiki/Runtime-code-generation-using-Roslyn-compilations-in-.NET-Core-App, they can either be found using packages (what the SDK does), or we can just compile against the implementation assemblies. In this change, I'm compiling against implementation assemblies, since that's fairly similar to what the tests do on mono, where they find them in the GAC.
For mono, the common references only included mscorlib. For .NET Core, I'm getting the common references from the "Trusted Platform Assemblies" (TPA) of the test process. As a result, package references of the test project become references during testcase compilation. Explicit references specified via `ReferenceAttribute` in a testcase are looked for alongside the host process's implementations as well (since we have no way to resolve a reference from just the filename since there is no GAC).
Other changes:
- Roslyn outputs the `DebuggableAttribute` by default but mcs does not, so when running on .NET Core, we don't check for the `DebuggableAttribute`.
- Check for core types in `System.Private.CoreLib` instead of `mscorlib`.
- There are some more edge cases that I'm in the process of cleaning up and will update soon.
At the moment, I'm trying to get the tests up and running, and I'm using plenty of compile-time conditions to modify the behavior on core. It would be nice not to have to do this - I haven't given it much thought, but maybe we could provide an abstraction that contains knowledge of the platform libraries, so that we don't have to have a hard dependency on `"mscorlib.dll"` and `"System.Private.CoreLib.dll"` everywhere? @mrvoorhe please let me know if you have any thoughts. Does the approach I'm taking so far seem sane to you?
@marek-safar
Diffstat (limited to 'global.json')
-rw-r--r-- | global.json | 3 |
1 files changed, 2 insertions, 1 deletions
diff --git a/global.json b/global.json index 66fe50044..a8cfd0ae5 100644 --- a/global.json +++ b/global.json @@ -3,6 +3,7 @@ "dotnet": "3.0.100-preview-010184" }, "msbuild-sdks": { - "Microsoft.DotNet.Arcade.Sdk": "1.0.0-beta.19125.2" + "Microsoft.DotNet.Arcade.Sdk": "1.0.0-beta.19125.2", + "Microsoft.NET.Sdk.IL": "3.0.0-preview4-27520-71" } } |