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.

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

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

Solution 3

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

Solution 4

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.

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

View more solutions

Comments

[Matt Canty]

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

[ili]

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.

[Matt Canty]

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!

[ashes999]

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

[Samuel]

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