System.BadImageFormatException when target framework is 4.0

Question

I have a run time exception after changing Target Framework to .net framework 4: A first chance exception of type 'System.BadImageFormatException' occurred in

When building with target framework 3.5, everything works fine.

The platform i am building to is x86 (i found out that building to x64 night cause the problem).

What can be the problem?

Answer 1

MSDN lists possible reasons for this, so I'd suggest running through this as a checklist:

• An attempt is made to load an unmanaged dynamic link library or executable (such as a Windows system DLL) as if it were a .NET Framework assembly.

• A DLL or executable is loaded as a 64-bit assembly, but it contains 32-bit features or resources. For example, it relies on COM interop or calls methods in a 32-bit dynamic link library.

• Components have been created using different versions of the .NET Framework. Typically, this exception occurs when an application or component that was developed using the .NET Framework 1.0 or the .NET Framework 1.1 attempts to load an assembly that was developed using the .NET Framework 2.0 SP1 or later, or when an application that was developed using the .NET Framework 2.0 SP1 or .NET Framework 3.5 attempts to load an assembly that was developed using the .NET Framework 4. The BadImageFormatException may be reported as a compile-time error, or the exception may be thrown at run time.

The idea is to make sure that all of your projects and dependencies are either compiled to target the same framework version, or a previous version; and that each of your projects are compatible in terms of bitiness; and if you're loading libraries dynamically, be sure to load them property (i.e. don't try to load native libraries as managed assemblies.)

Perhaps adding some more information about the configuration / dependencies of your project(s) would allow us to be more decisive.

Answer 2

Make sure all the projects in your solution are building to x86 or x64 or Any Cpu - any mismatch can cause this problem.

Equally, if you are using any third party libraries - check out their target platform too.

Another thing to consider is whether this is being hosted in IIS - in which case you have to make sure that the bitness of your assemblies matches the bitness of the IIS hosting process. If you're on an x64 machine, then that's likely to be x64 (unless 32 bit hosting has been enabled).

I have to say I generally don't deviate from Any CPU unless I have an external dependency on a COM component that's x86 or x64 only. It nearly always causes headaches.