Nunit.exe cannot work on Vista 64bits if x86 build

Question

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

Positive

Answer 1

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

Positive

I am not the owner of the website. But, at least, I have written the answer :) so it does not really matter. – Positive

nunit-x86.exe is built for testing a 32-bit application on a 64-bit system. See detail explanation here: nunit.org/index.php?p=nunit-gui&r=2.4.2 – Malvinamalvino

Answer 2

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

Defer

You are right, I do not see *32 after Nunit.exe. I will check your link and will be back to you. +1 for the hint! – Positive

Doesn't work. I have try on an other file and it works. But Nunit doesn't. I have error CF001 : could not open the file for writing. The file is not read only... – Positive

Answer 3

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:

<NUnit Assemblies="Test/bin/$(Platform)/$(Configuration)/Test.dll" Platform="x86" /> 

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

Bidget

Answer 4

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.

Glorify

ANY Cpu has been changed to X86. I am running on ANY Cpu... not on x64 because I wasn't able to Debug with breakpoint and editing on X64. – Positive

Answer 5

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

Abyssinia

Answer 6

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

Mosul