nUnit Exception on a 64 bit Machine

Question

I have an MVC 3.0 app. My testing framework is nUnit 2.4.8.0. I started this code on a 32 bit machine, and recently started using a 64 bit machine. I just as recently upgraded the project to .NET 4.0.

My application runs fine - I am able to hydrate my objects from the database appropriately. The issue is when I run my integration tests.

The tests fail, and give an exception I've never seen before:

NHibernate.ADOException : cannot open connection
  ----> System.BadImageFormatException : An attempt was made to load a program with an incorrect format. (Exception from HRESULT: 0x8007000B)

I've searched online for this exception - It's of course a problem with nUnit, despite the NHibernate exception (remember, NHibernate allows me to hydrate and persist objects when I run the app).

I upgraded my nUnit assembly to the most recent release, version 2.5.10, and updated the reference in the project to the assembly under the 'net-2.0' folder of the nUnit zip file. I ran the tests again, and received the same exception.

It seems that there is some sort of 32-bit vs 64-bit conflict between assemblies, code, and the ASP.NET Development Server.

I don't have any experience dealing with 32-bit vs 64-bit issues, so I don't know if there are other questions on stack overflow that are relevant (the ones I've seen seem not to be). I have some ideas, but no answers:

• Do I need a different nUnit assembly?
• Do I need to change the Solution Platform setting in VS2010? (It's currently on "Any CPU")
• Do I need to change build properties of my integration tests project?
• Do I need to change configuration settings of my solution?

Unfortunately I don't have a 32-bit machine around to test the code on at the moment. Are any of the above questions on the right path to solving this? Can you offer any guidance?

Thanks.

UPDATE: I'm really hoping to be able to run the tests from within Visual Studio using TestDriven.NET. I don't want to have to start using the nunit UI to run my tests.

UPDATE 2: Sorry, I may not have been clear. I'm not yet using TestDriven.NET, what I said is that I'm hoping to use it, but I haven't installed it yet on the new x64 machine. At this moment, I'm trying to run the tests by clicking on the visual icon inside the Visual Studio IDE, as in the image below:

Following through with that action, the tests fail, and the dialog that pops up displays the following:

That is the exception that I quoted up above. There is no reference to assemblies that haven't loaded.

At first I didn't believe that the version of NHibernate (2.0.1.4000) I am using would matter; I say this because the providers are able to return the desired objects from the database when the app is run. However, When I debug the test, I see that the exception is being thrown in my provider. When digging down a bit, It seems the source of this is my SQLite assembly. But again, this is the same assembly that works when I run the project - why would it not work when I run the integration tests?

Answer 1

The nUnit-x86.exe is the 32 bit executable whereas nUnit.exe is the 64-bit one. So use the 32-bit executable to see if that solves things.

Use AnyCPU for DLLs. It's the setting for the exe that loads the dll that causes this problem. (32 bit exe cannot load 64 bit dlls or vice versa).

Answer 2

This is a problem I get regularly.

System.Data.SQLite is a 32 or 64 bit specific assembly as it bundles a native image for SQLite inside the DLL. The NUnit test runner is trying to run it in the wrong mode i.e. a 64-bit assembly in a 32-bit test runner and it's going bang when it tries to make a native call to the SQLite C API. Windows can't do that.

I suggest you standardise across all platforms on either 32-bit or 64-bit i.e. your dev environment and your deployment environment.

An intermediate fix will be to replace the SQLite DLL with a 64-bit one as available from here: http://system.data.sqlite.org/. this may however break at deploy time at which point you will need to create a build configuration for your live environment which ships the right DLL version (32/64-bit).

Getting NUnit to deterministically run in either 32 or 64 bit mode is a pain so I wouldn't bother with that personally.