Convert to .NET Core 3.0

[Pilchie]

No description provided.

[Pilchie]

@jaredpar @jmarolf @DustinCampbell Should convert the other projects of course, and no idea if the nuget package generation still works (probably not).

[Pilchie]

@bradwilson it looks like AssemblyHelper went internal between 2.1.0 and 2.4.1. Any idea on what we're supposed to use instead?

[bradwilson]

Given dependency resolution order (especially in .NET Core), it wasn't possible for that class to exist in xunit.runner.utility.dll, because it is required to successfully locate and load xunit.runner.utility.dll. So it became an internal class that was imported into each runner.

There is really no way for us to provide this as a DLL to you as a result. :(

[Pilchie]

So, what's a third party runner to do? Currently we use it here: https://github.com/Pilchie/xunit.runner.wpf/blob/master/xunit.runner.worker/XunitUtil.cs#L12

[Pilchie]

@jaredpar seems like once this is merged, you could do your original plan to multi-target the worker process and have it run on either .NET Core or .NET Framework, or maybe both (though that might be difficult, as you'd need different publish directories?)

[jaredpar]

any particular reason you're keeping this at such an old version?

[Pilchie]

It had to do with one of the NuGet package dependencies. I think it was the XUnit issue that I'm discussing with @bradwilson.

[Pilchie]

Okay, updated to net472 for the worker and netstandard2.0 for data and the sample unit test assembly.

[bradwilson]

So, what's a third party runner to do?

We can't provide you with a binary that works, so you'll have to take a copy of the source for yourself, I'm afraid. 😞

[jaredpar]

Yeah I should get on the multi-target idea so that we can support CoreCLR here.

[Pilchie]

Need to figure out how to get appveyor to install and use a local dotnet, and then I can probably merge this.

Note that it stops making it a package that you can reference, and turns it into a global tool instead.

[Pilchie]

@bradwilson I did that for desktop - I took a peek at doing it for .NET Core, but it seems like that pulled in a bunch of other dependencies (in the form of DependencyContext and friends) 😦

[bradwilson]

...and that .NET Core code is the code you can't really trust to always do the right thing, I'm afraid. It's why we killed dotnet xunit and the CoreCLR xunit.console.dll.