Could not load file or assembly exception

BadImageFormatException usually means 64 vs 32 bit conflict. One of the assemblies is set to a specific platform i.e. 64 bit or 32 bit while the other is set or defaults to a different one. Check if both assemblies are for the same platform, preferably "Any CPU". In other words it could be that a 64 bit assembly is trying to load 32 bit one or vice versa.

This also applies if you're calling a COM or a DLL which is compiled for different platform, for example you call 32 bit COM/DLL from an assembly on a 64 bit system where assembly's platform would default to x64. In this case adjust your assembly's platform to match.

To change platform go to project Properties -> Build -> Platform.

I had this issue, when trying to use 64-bit .dlls in my ASP.Net project, in Visual Studio 2013.

The solution was to click on Tools\Options, and tick this box:

Ok the answer is Got to Start->Run->type inetmgr and on the left application pools, select DefaultAppPool and the virtual directory name of the app and for both make sure to enable 32 -bit applications to true, am using IIS7.0 and windows 7 64-bit.

The most common cause in my experience is that you made a change to a referenced assembly that requires rebuilding other assemblies using that changed assembly, and didn't rebuild them.

Example #1: you have an EXE that references a DLL. You add something to the referenced DLL that adds a new method, new parameter, whatever. This changes the external "signature" of the DLL; that is, the location in memory of various entry points. You don't rebuild the EXE. When the EXE loads and tries to reference the new DLL, its old entry point is no longer valid, so it cannot execute the code it needs.

Example #2: you have an x86 EXE that references a DLL. This DLL must also be compiled for x86 (or Any CPU). If you rebuild it for x64, the EXE, running in a 32-bit space, will not understand the instructions and register references to the 64-bit "extended" world, and will cry uncle.