System.BadImageFormatException caused by NUnit project

Question

Good day everyone. I have been having the same problem all day at work and am struggling to find any new paths to go down.

I am getting the following error when my solution builds on server. I have no problem running/debugging all tests in the solution and it builds fine. Both server and my PC are x64. I have followed a lot of advice which I have found to no avail.

I have set Platform Target to x86 for all projects in my solution under all configurations.

I am aware that there is an nunit-console-x86.exe which could make all the difference but I'm not sure where to specify this in the code.

Please realise I have trail-blazed the internet, so apologies if I have missed something.

System.BadImageFormatException: Could not load file or assembly
'Spin.TradingServices.DataAcquisition.Test.NUnit, Version=1.0.12103.2060, Culture=neutral, PublicKeyToken=null' or one of its dependencies. An attempt was made to load a program with an incorrect format.
File name: 'Spin.TradingServices.DataAcquisition.Test.NUnit, Version=1.0.12103.2060, Culture=neutral, PublicKeyToken=null'

Server stack trace: at System.Reflection.RuntimeAssembly._nLoad(AssemblyName fileName, String codeBase, Evidence assemblySecurity, RuntimeAssembly locationHint, StackCrawlMark& stackMark, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks) at System.Reflection.RuntimeAssembly.InternalLoadAssemblyName(AssemblyName assemblyRef, Evidence assemblySecurity, StackCrawlMark& stackMark, Boolean forIntrospection, Boolean suppressSecurityChecks) at System.Reflection.Assembly.Load(AssemblyName assemblyRef) at NUnit.Core.Builders.TestAssemblyBuilder.Load(String path) at NUnit.Core.Builders.TestAssemblyBuilder.Build(String assemblyName, Boolean autoSuites) at NUnit.Core.Builders.TestAssemblyBuilder.Build(String assemblyName, String testName, Boolean autoSuites) at NUnit.Core.TestSuiteBuilder.BuildSingleAssembly(TestPackage package) at NUnit.Core.TestSuiteBuilder.Build(TestPackage package) at NUnit.Core.SimpleTestRunner.Load(TestPackage package) at NUnit.Core.ProxyTestRunner.Load(TestPackage package) at NUnit.Core.ProxyTestRunner.Load(TestPackage package) at NUnit.Core.RemoteTestRunner.Load(TestPackage package) at System.Runtime.Remoting.Messaging.StackBuilderSink._PrivateProcessMessage(IntPtr md, Object[] args, Object server, Int32 methodPtr, Boolean fExecuteInContext, Object[]& outArgs) at System.Runtime.Remoting.Messaging.StackBuilderSink.SyncProcessMessage(IMessage msg, Int32 methodPtr, Boolean fExecuteInContext)

Exception rethrown at [0]: at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg) at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type) at NUnit.Core.TestRunner.Load(TestPackage package) at NUnit.Util.TestDomain.Load(TestPackage package) at NUnit.ConsoleRunner.ConsoleUi.Execute(ConsoleOptions options) at NUnit.ConsoleRunner.Runner.Main(String[] args)

WRN: Assembly binding logging is turned OFF. To enable assembly bind failure logging, set the registry value [HKLM\Software\Microsoft\Fusion!EnableLog] (DWORD) to 1. Note: There is some performance penalty associated with assembly bind failure logging. To turn this feature off, remove the registry value [HKLM\Software\Microsoft\Fusion!EnableLog].

http://app1017-build.oy.gb.sportingindex.com:8080/job/TradingServices.DataAcquisition-Dev/ws/DataAcquisition/build.proj(86,5): error MSB6006: "nunit-console.exe" exited with code -100. Done Building Project " (default targets) -- FAILED.

Build FAILED.

PLEASE NOTE: We have reverted our build on Hudson and now re-committing files more gradually. I will report back on how this goes. Tried get a few heads involved on this one to no avail unfortunately. Shame!

Update I haven't been back to this page for a while but it looks like there are lots of different solutions. If I could mark them all as the answer I would! Those of you finding your way here should probably give equal credit to each option.

Descender

For people that found this question via search engine, but their problem occurs on a build server like Jenkins — have a look at this question: #58876301 – Role

Answer 1

Check the target framework version of your assembly are same as nUnit test runner supports. See runFile.exe.config for list of supported runtimes.

Also if you have megrated from FW 3 to FW 4, they has different runtime (CLR is different).

Florentinoflorenza

All of our projects are using .Net Framework 4. And have been since I started here. These tests were running last week until a commit on Friday, and its just hard to tell what change has been made. Supported RunTimes are from v1.0.3705 to v 2.0.50727 – Descender

FW 4 runtime is 4.[yah i don't remember next :)] Runtime 2.xxx is FW 2, 3, 3.5. So try to look forward this way. Update nUnit, verify paths... etc. – Florentinoflorenza

Answer 2

I had this problem with a console app on X64 pc, the build was set as x86 and it still crashed. I went into Properties on the Console App and under build I changed my Platform Target from x86 to Any CPU then suddenly all the tests worked and ran successfully.

of note, the Configuration Manager's platform field can "lie" to you and doesn't actually have to reflect what the project's properties are actually configured to do. My configuration manager said that "Common.dll" was being built as "Any CPU", but the project properties (the setting that really matters) was building it as "x86".

Susurration

Yeah, I think we must have tried this. It turned out to be a completely unrelated part of our project which no-one in our team had worked on. So we commented it out (unused now) and it worked... Nothing learned! – Descender

In a lot of cases, you can just change the platform target but in other, you simply can't. For example, if you have to connect to MSAccess database, the platform target must be x86. I know, it's bullsh... but hey guys, it's Microsoft.... a hate/love relationship. :D – Atrium

Answer 3

Make sure that this setting is correct: Test menu -> Test Settings -> Default Processor Architecture -> x64 / x86. It was incorrect in my case and it failed with the same issue.

Postdoctoral

In VS2019 this is now a Top Level Menu Setting. Test > Processor Architecture for Any CPU Projects > (choose setting) – Groundling

Answer 4

A minor addition to all answers. You might need to change the NUnit runner platform (Resharper for me) itself as it was in my case. See example

Zigrang

Answer 5

I come across this often, when I test against Console or WPF application. A few causes are

• First, make sure you application doesn't run on .Net Framework 3 or 4 Client profile
• Then compare the target framework .NET version on both application and test projects. They should be the same
• Check Platform target on build tab. They should be the same. For example, if test project has "Any CPU" target, the application must have "Any CPU".

Kaitlin

Answer 6

For me, the exception was caused by invalid /process=single argument of nunit. If I change the value, then the exception is gone:

/process=separate

or

/process=multiple

p/s: late answer, but just for reference..

Forland

Answer 7

This might sound stupid, but, check your project and processor architectures. In my case, I was running 64-bit tests on what I assumed was a 64-bit machine (since it was building 64-bit projects).

Guess what? It was actually a 32-bit machine. So NUnit.exe ran as 32-bit (obviously), and can't understand 64-bit tests.

The solution? Build a x86 and x64 version of your tests, and run the x86 ones on the x86 machines, and the x64 ones on the x64 machines.

Obvious. But worth checking out.

Marielamariele

Answer 8

My situation was a bit different. The error appeared quite randomly after running a Unit Test that had been modified.

I removed the test and the error went away.

I recreated the test and the error came back.

I renamed the test and the error went away.

I renamed the test back and the problem did not happen again.

Hope this helps!

Ben

Verbalism

Answer 9

Thanks Ashes999 for waking me up.

This problem did return again. And rolling back and uploading with didn't work. It turned out to be a monitor object which we no longer even use. Commented out and fixed.

The way to find this is by doing Debug All Unit Tests. Fix everywhere it pauses. If t doesn't pause then err.

Descender

Thanks for the details. I don't even use monitors, so this didn't fix my problem. I'll post my own answer. – Marielamariele

Answer 10

For anyone still having this issue, you also may need to set the framework field on the test runner to match the one in your included project (The field just to the right of the one referenced by AlexM).

In my case, I was writing a test suite for a Windows Phone 8 library, and NUnit was unable to correctly figure out the framework version that it should use.

Breland

Answer 11

I was also getting same issue.

For me solution was to uncheck the "Prefer 32-bit" checkbox on project properties.

Izanagi