Menu
I'm porting a small library that I have on NuGet to .NET Core.
I've created .NET Standard 1.6 class libraries for the main project and the tests, and copied over the code. I changed the unit tests to use xUnit attributes and asserts rather than NUnit.
Other than that, I pretty much followed the instructions in the documentation, and thus I added the following NuGet packages:
Alas, (1) Test Explorer does not find my unit tests, and (2) when I run dotnet test, I get the following:
Starting test execution, please wait... Could not find testhost.dll for source '[...].Tests.dll'. Make sure test project has a nuget reference of package "microsoft.testplatform.testhost".
I have actually added the suggested Microsoft.TestPlatform.TestHost NuGet package, but that hasn't changed anything.
So what is the problem here?
I'm using Visual Studio 2017. Not that I think it makes a difference.
Update: changing the test project from Class Library (.NET Standard) to Class Library (.NET Core) fixed the problem. I still don't get why this is supposed to make a difference.
334
The xUnit.net test runner that we've been using supports . NET Core 1.0 or later, . NET 5.0 or later, and . NET Framework 4.5.
To write a test you simply create a public method that returns nothing and then decorate it with the Fact attribute. Inside that method you can put whatever code you want but, typically, you'll create some object, do something with it and then check to see if you got the right result using a method on the Assert class.
I've been using xUnit for quite some time now, and it's my Unit testing framework of choice. It's an open source unit testing tool for . Net framework that's compatible with ReSharper, CodeRush, TestDriven.Net, and Xamarin. You can take advantage of xUnit.Net to assert an exception type easily.
Changing the test project from Class Library (.NET Standard) to Class Library (.NET Core) fixed the problem. I still don't get why this is supposed to make a difference.
Unit tests are applications that we run. To build such an application, we must specify a runtime and application model. When we target .NET Standard, the runtime and application model are ambiguous; MSBuild does not know whether to build against .NET Framework, .NET Core, Mono/Xamarin, or another .NET Standard compliant platform. Targeting .NET Core provides the required input to MSBuild, which now knows how to resolve all the referenced assemblies/projects and choose the appropriate framework version.
But that was never the case. In the past, you would always use a class library for unit tests; it was never considered an application that you could run, but rather a collection of classes and methods that you would feed into a test runner.
In the past we did not have .NET Standard, which is an ambiguous target. When MSBuild sees .NET Standard it needs more information. "Okay, which .NET Standard compliant runtime do you want to use to produce the runnable output?" If for instance we had targeted netstandard1.2, then MSBuild would not know whether to build against .NET Core 1.0, .NET Framework 4.5.1, Windows 8.1, or the several other netstandard1.2 compliant platforms.
Starting test execution, please wait... Could not find testhost.dll for source '[...].Tests.dll'. Make sure test project has a nuget reference of package "microsoft.testplatform.testhost".
If we do not specify netcoreapp, then MSBuild assumes that we are using the full framework. In that case, it expects the target assemblies, including testhost.dll, to be in the bin. If they are not (and they will not be if we built against .NET Standard), then we will receive the above error.
86
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
