27
votes

I am on Vista 64 bits and I have a project built with x86 configuration. All work fine. Now, we are at the time to create test. We have NUnit 2.4.8 but we have a lot of problem.

The test are loading trough the Nunit.exe (gui) when we select the .dll directly but when executing we have a system.badimageformatexception.

I have read by searching on Google few trick about the nunit.exe.config but none work. (changing to UTF8... uncomment .net version for startup).

Any idea?

Update

I have clean the solution and erase all BIN folder. Now when I compile I clearly see that I have only the /x86/ in the bin directory and not the old /debug/ that was in x64.

When I go with Nunit I have an exception (in the loading) : System.IO.FileNotFoundException...

Server stack trace: at System.Reflection.Assembly._nLoad(AssemblyName fileName, String codeBase, Evidence assemblySecurity, Assembly locationHint, StackCrawlMark& stackMark, Boolean throwOnFileNotFound, Boolean forIntrospection) at System.Reflection.Assembly.InternalLoad(AssemblyName assemblyRef, Evidence assemblySecurity, StackCrawlMark& stackMark, Boolean forIntrospection) at System.Reflection.Assembly.InternalLoad(String assemblyString, Evidence assemblySecurity, StackCrawlMark& stackMark, Boolean forIntrospection) at System.Reflection.Assembly.Load(String assemblyString) 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.Util.TestLoader.LoadTest(String testName)

Update 2

I am compiling with ANY CPU that I have modified to be x86 instead of x64. The reason is for the debug. This has been already discussed in the previous link. I have to confirm that NUnit is running in 64bits mod and Corflags.exe

6

6 Answers

52
votes

Ok I found the solution in this website. You have to use the \NUnit-2.4.8\bin\nunit-x86.exe instead of \NUnit-2.4.8\bin\nunit.exe... didn't know that the \bin\ had 2 nunit!!!

Thx all

5
votes

The NUnit host is likely running as a 64 bit process (you can confirm that by looking in task manager). If you assembly is x86 only then it won't be able to run in that process.

You can try running corflags on the NUnit executable to force it to run x86, using the /32bit+ flag

4
votes

This can also happen when upgrading from TeamCity 3.1 to 4.0 on an x64 build server with the MSBuild Run Platform set to x86. The TeamCity runner seems to default the platform differently in 4.0 than 3.1, not honouring the fact that the build is running x86.

In my case, the first fix that worked was adding a Platform override to the NUnit call in my MSBuild script:

&ltNUnit Assemblies="Test/bin/$(Platform)/$(Configuration)/Test.dll" Platform="x86" /&gt 

(i.e., the TeamCity test runner way of forcing 32 bit as in the other suggestions)

(This includes when the platform target for the test assembly is Any CPU (although as it happens I have set them to x86 explicitly as some tests dynamically load DLLs that are constrained to x86)).

0
votes

Why are you using the x86 configuration and not Any CPU?

I'd imagine that when you load NUnit it's been built with the Any CPU option, so JITs to x64 code. When this tries to load your tests which are specifically compiled to run as x86 it throws the exception.

I'd try changing all your configuration settings to Any CPU and see if this solves your problem.

0
votes

If using TeamCity, you can add the property teamcity.dotnet.nant.nunit2.platform with the value x86 to the Build Parameters in your TeamCity project's configuration settings (in the Properties and Environment Variables section).

0
votes

Had the same problem with TeamCity 8.1. What solved it was changing NUnit build step .NET Runtime / Platform: to x86

I also had to change Run tests from: path from TestProject\bin\Release to TestProject\bin\x86\Release