search

Pilchie / xunit.runner.wpf

XUnit Gui written in WPF
Apache License 2.0
44 stars 41 forks source link

Convert to .NET Core 3.0 #86

Open Pilchie opened 5 years ago

Pilchie commented 5 years ago

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

bradwilson commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

@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?)

bradwilson commented 5 years ago

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 commented 5 years ago

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

Pilchie commented 5 years ago

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 commented 5 years ago

@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 commented 5 years ago

...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.