Could not load file or assembly 'B.DLL' or one of its dependencies

Question

Along with: An attempt was made to load a program with an incorrect format

I have A.EXE that references B.DLL. Both are mine. Both are set to x86 for the platform target. B.DLL references:

System
System.Data
System.Windows.Forms
System.XML

I am using VS2010 on Win7 64-bit. All search results I can find say that this is because of loading 32-bit assemblies into 64-bit executables or vice versa. However I have checked and rechecked that A.EXE and B.DLL are set to use "x86" as the platform target. I've also tried cleaning and rebuilding the entire solution. B.DLL builds with no errors or warnings.

This is a previously working project. I'm currently working on refactoring it by moving some code out of A.EXE an into the newly-created B.DLL.

I tried setting A.EXE to "Any CPU" and it didn't help (I didn't expect it to). Changing it back to "x86" didn't help either.

I am targeting .NET 3.5

Update

I created a new C# class library C.DLL and added a reference to B.DLL. C.DLL is set to x86 and it compiles fine.

Update

The compile-time error occurs in MainForm.resx at a closing "data" tag:

  <data name="StatusStripImages.ImageStream"
  mimetype="application/x-microsoft.net.object.binary.base64">
    <value>
    ...
    </value>
  </data>

Update

I now suspect resgen.exe. I tried forcing it to be 32-bit and I broke it (see: http://social.msdn.microsoft.com/Forums/en-US/vseditorprerelease/thread/6782c692-a9b6-4930-a099-4ee4092e91a9).

Any ideas?

thanks, Andy

Answer 1

You can verify if the 32bit flag is correctly set on both assemblies by running "corflags" against them.

Answer 2

Generally the exception BadFormatException occurs when a dll is built in x86 is tried to be loaded in x64 application.

In your project properties Recheck if the Platform Target is set both either to x86 or to x64. Mixing up both creates an issue.

Answer 3

There are not a lot of a failure modes here. But do keep in mind that the Target Platform setting is separate for the Debug and the Release version. And that the configuration name in VS2010 doesn't actually have anything to do with the Target Platform setting. In other words, you can change the Target Platform but it will still be named "x86" in Build + Configuration Manager. Tricky.

So double-check your assumptions. Actually verify the Target Platform combo for both configurations. And Bob's recommendation to triple-check with Corflags.exe is a good idea. Run it from the Visual Studio Command prompt. Only the EXE setting matters, the DLLs have to follow suit with what the startup assembly demanded. There are additional failure modes if your code gets started by other means than a EXE. Like a unit-test runner.

Answer 4

It seems I am suffering from a bug [1] in Visual Studio 2010 that Microsoft can't be bothered to fix even though they've known about it for months.

There are three workarounds and I just changed A.EXE and B.DLL from .NET 3.5 to .NET 4.0 to solve it. Not ideal but I didn't want to make changes to resgen.exe. I guess I have to wait for SP1 to be able to target .NET 3.5.

[1] http://blogs.msdn.com/b/visualstudio/archive/2010/06/19/resgen-exe-error-an-attempt-was-made-to-load-a-program-with-an-incorrect-format.aspx