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

您可以通过对两个程序集运行“ corflags”来验证是否在两个程序集上正确设置了32bit标志。

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

FIX

I was suffering from the exact issue described by the current accepted answer for this question that points to the link below

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

However, after eading this:

https://connect.microsoft.com/VisualStudio/feedback/details/532584/error-when-compiling-resx-file-seems-related-to-beta2-bug-5252020

It appears that if you open the failing .resx file you will a line similar to

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

There is a block of data within this element. The first line reads

AAEAAAD/////AQAAAAAAAAAMAgAAAFdTeXN0ZW0uV2luZG93cy5Gb3JtcywgVmVyc2lvbj00LjAuMC4w

Simply replace last 0 with a y making the line read

AAEAAAD/////AQAAAAAAAAAMAgAAAFdTeXN0ZW0uV2luZG93cy5Gb3JtcywgVmVyc2lvbj0yLjAuMC4w

This worked for me straight away. I like how it spells out j0y . Not a great fix but it's the best I've seen short of a fix.

j0y ,

----Nanook

Answer 5

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