visualstudio.xunit
visualstudio.xunit copied to clipboard
net462 support for xunit.runner.visualstudio
Hi!
Thanks for this awesome test framework!
I was trying with latest version of xunit.runner.visualstudio 2.4.1, in a unit test project even though when I set to run using sku=4.6.2 in app.config the test host is still using the xunit.runner.utility.net452.
<startup>
<supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.6.2" />
</startup>
Any ideas to make it run under 4.6.2? Or is this still not there yet?
Thanks!
Moving this issue to the correct repository...
Sorry for raising the issue against the wrong one! :)
No worries 😊
There's ever only one version of the .NET Framework on a machine. The xUnit libraries are compiled for .NET 4.5.2, but if you have a later one installed, it'll be running on that.
Thanks @onovotny for the reply. I do have later versions of .net installed on my machine. But it seems because it was compiled against .net 4.5.2 is not able to use some TLS 1.2 settings, however if I move same piece of code I had in a unit test it just works fine from a console app targetting 4.6.2 (background is I was trying to setup an integration test to connect to Dynamics CRM online, which requires 4.6.2 now, so the console app can connect fine, whereas the xUnit runner can't). Any chance we could force it to use 4.6.2 or could we have runners compiled against newer .net versions?
I have unit tests that verify manipulation with CultureInfo. The production code uses async
a lot and therefore the tested code relies on .net 4.6 feature that copies CultureInfo to newly spawned threads. My unit tests work well with xunit.console (.NET 4.7.2), but they do not work with vs runner (.NET 4.5). I pulled your source code and changed framework to 4.7.2 and tests started to work with vs runner as well.
Would it be possible to compile the runner against a newer version of .NET framework?
@clairernovotny is there some progress on this? Why VS Studio can't select runner compiled against same version as test project?
It doesn't help now, but this problem goes away with the v3 architecture when we ship it later this year, because your unit tests become their own executable program rather than just a DLL. This means you pick the exact version of the .NET Framework SDK you want, and get the exact behavior you need.
Thanks @bradwilson! I like this decision but as you already say, it doesn't help us right now.
Closing as an external issue since this is mostly a question for VSTest in how they choose to spin up the test process (something we do not control).