NUnit failed to load DLL

Question

When you try to run unit tests in Visual Studio, you receive the following error message:

NUnit failed to load w:\Repos\trading.tools\Trading.Tools.Test\bin\x64\Debug\Trading.Tools.Test.dll 

I use

• Visual Studio 2013 Community
• NUnit Adapter 3.4.0.0
• NUnit 3.4.1

It is strange that I have another project that is configured in the same way as this one, and it works great.

I also downloaded NUnit 3.4.1 and installed it. When i started

 nunit3-console.exe Trading.Tools.Test.dll 

everything works perfectly. Any ideas what I can do?

Thanks a lot Konstantin

Edit # 1

Here is the full console output from Visual Studio when trying to run all the tests.

 Test run will use DLL(s) built for framework Framework45 and platform X86. Following DLL(s) will not be part of run: Trading.Tools.Test.dll, Trading.Tools.dll are built for Framework Framework45 and Platform X64. Go to http://go.microsoft.com/fwlink/?LinkID=236877&clcid=0x409 for more details on managing these settings. NUnit Adapter 3.4.0.0: Test discovery starting NUnit failed to load w:\Repos\trading.tools\Trading.Tools.Test\bin\x64\Debug\Trading.Tools.Test.dll Assembly contains no NUnit 3.0 tests: w:\Repos\trading.tools\Trading.Tools\bin\x64\Debug\Trading.Tools.dll NUnit Adapter 3.4.0.0: Test discovery complete 

As you can see, it is very obvious that NUnit is expecting an x86 build, but I'm building for the x64 platform. And again, my x64 build works fine if I performed it using nunit3-console.exe .

What I see in the csproj :

 <Reference Include="nunit.framework, Version=2.6.4.14350, Culture=neutral, PublicKeyToken=96d09a1eb7f44a77, processorArchitecture=MSIL"> <SpecificVersion>False</SpecificVersion> <HintPath>..\packages\NUnit.3.4.1\lib\net45\nunit.framework.dll</HintPath> </Reference> 

The strange thing is that it indicates the use of Version=2.6.4.14350 , but refers to dll 3.4.1.

So, the next question from this point - how can I make NUnit to complete my x64 build? Any ideas?

Answer 1

I had a similar problem, the key point is that it is Test Runner in Visual Studio that only x86 builds will be tested. Based on this, I assume that it forces the use of the x86 NUnit runner. To change this (at least in VS2015 and VS2017), Test Settings Test > " Test Settings >" Default Processor Architecture > " X64 .

Answer 2

You can also set the execution target in the settings file. Then you should select this file. This should make the solution more stable. A runsettings file that only installs this might look like this:

To enable it, do as shown in the figure below:

When you select it from the test menu (1), it will be added as selected in the menu (2), and after that Rebuild will do the test in the Testers Explorer (3)

There is an added bonus to using the runsettings file, which means that it will work correctly in the TFS build system if you use this. I wrote a blog post on this issue, see http://hermit.no/how-to-control-the-selection-of-test-runner-in-tfsvsts-making-it-work-with-x86x64-selected -targets /

Answer 3

I managed to get this error while writing the unit test method. And I noticed the main reason for the absence of one of the dependent dlls to load. This error ("NUnit could not load the .dll") was shown in the "Exit" ("Test") window after changing the test method code and trying to run it. After updating the nuget package for the dependent dll, nunit started compiling the test project DLLs and the test cases were completed.

Answer 4

I could not run my tests and found this to be one of the problems. Turns out my TestFixture was internal . Just switching to a public issue solved my case.

Answer 5

After an unsuccessful attempt of all the other answers above, the following worked for me:

In my case, the project and .NET solution are on a mounted drive (I use MacBook and Parallels for .NET development). The mount also contains the locations of / bin / debug and / bin / release, from which NUnit tried to read the "test" DLL.

The fix was to move the solution / project files to the C: drive of my Windows image. Tests were discovered immediately.

Apparently the overall / mounted location was not to their liking. I do not know why, since the mount is permanent and read / write to all users of the Windows image. I suspect that problems with file permissions, or possibly somehow all mounts, are not available to the user / process that runs the NUnit discovery logic.