NUnit exception on a 64-bit machine

Question

I have an MVC 3.0 application. My testing platform is nUnit 2.4.8.0. I started this code on a 32-bit machine and recently started using a 64-bit machine. I also recently upgraded the project to .NET 4.0.

My application works fine - I can remove my objects from the database accordingly. The problem is when I run my integration tests.

Tests fail and give an exception that I have 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 searched the Internet for this exception. Of course, the problem with nUnit, despite the NHibernate exception (remember, NHibernate allows me to moisten and save objects when the application starts).

I updated my nUnit build to the latest version 2.5.10 and updated the build link in the net-2.0 folder of the nUnit zip file. I checked the tests again and got the same exception.

There seems to be a 32-bit, 64-bit conflict between the builds, code, and the ASP.NET development server.

I have no experience with 32-bit and 64-bit issues, so I don’t know if there are other stack overflow issues that matter (the ones I saw seem to be wrong), I have some ideas, but no answers:

• Do I need another nUnit build?
• Do I need to change the solution platform configuration in VS2010? (It is currently included in "Any processor")
• Do I need to change the build properties of my integration test project?
• Do I need to change the configuration settings of my solution?

Unfortunately, I do not have a 32-bit machine for testing code at the moment. Is there any of the above questions on the right path to solving this? Can you offer any recommendations?

Thanks.

UPDATE: I really hope that I can run tests from Visual Studio using TestDriven.NET. I don't want to start using the nunit user interface to run my tests.

UPDATE 2: Sorry, I might not have been clear. I am not using TestDriven.NET yet, I said that I hope to use it, but I have not installed it on a new x64 machine yet. At this point, I'm trying to run the tests by clicking the icon in the Visual Studio IDE, as shown in the image below:

Following this step, the tests fail and a popup dialog displays the following:

This is the exception that I quoted above. There are no links to assemblies that are not loaded.

At first I did not believe that the version of NHibernate (2.0.1.4000) that I am using matters; I say this because providers can return the desired objects from the database when the application starts. However, when I debug a test, I see that my provider throws an exception. When you dig a little, it seems like this is my SQLite build. But then again, this is the same assembly that works when I run the project - why doesn't it work when I run integration tests?

Answer 1

This is a problem that I regularly get.

System.Data.SQLite is a 32 or 64-bit specific assembly, as it links its own image for SQLite inside a DLL. The NUnit tester tries to run it in the wrong mode, i.e. a 64-bit build in a 32-bit test runner, and it will beat when it tries to create its own SQLite C API call. Windows cannot do this.

I suggest you standardize on all platforms either 32-bit or 64-bit, that is, a development environment and a deployment environment.

An intermediate solution is to replace the SQLite DLL with the 64-bit version available here: http://system.data.sqlite.org/ . this may, however, break during deployment, after which you will need to create an assembly configuration for your live environment that will send the correct version of the DLL (32/64-bit version).

Getting NUnit for deterministic launch in 32-bit or 64-bit mode is a pain, so I would not worry about that.

Answer 2

nUnit-x86.exe is a 32-bit executable file, while nUnit.exe is 64-bit. So use a 32-bit executable to find out if this solves something.

Use AnyCPU for DLL. This is a setting for exe that loads the dll that causes this problem. (The 32-bit version cannot load 64-bit DLLs or vice versa).

Answer 3

From the screenshots you can see that you are using the Resharper test runner.

In my experience, the Resharper tester uses the corresponding bit specified by the test assembly loaded into the host environment.

Thus, if you have a project in the test stack that depends on 32-bit (i.e. x86), then (for example, a project under testing installed for assembly as x86 in the current configuration of the assembly or a project with a link to the assembly, marked as x86), then it will be useful for you to mark everything that consumes this thing (including test projects) for assembly as x86.

The launch of a test project set up to build as x86 through the visual studio test runner of the visual studio is loaded in a 32-bit process and successfully runs the tests on the assembly, which is also marked as x86.

And, the problems of supporting multiple platforms.