Visual Studio 2012 adds reference to wrong DLL

Question

I was having trouble getting Visual Studio to build my project in release mode... it gives me errors about assemblies being the wrong format. Turns out some x86 assemblies were being referenced instead of x64 assemblies. Assemblies like PresentationCore, System.Data and so on.

Things I've tried:

• Debug mode, any CPU builds fine.

• Debug mode, x64 builds fine.

• Release mode, any CPU fails

• Release mode, x64 fails (this is the combination I'd LIKE to build my project in)

The issue comes when I try to remove the x86 reference and switch it to a x64 reference. Visual studio just adds the old x86 reference instead of the x64 reference. For example:

I remove the System.Data reference which is in C:\Windows\Microsoft.NET\Framework\v2.0.50727\System.Data.dll

I browse to and add C:\Windows\Microsoft.NET\Framework64\v2.0.50727\System.Data.dll, but when I click on that System.Data reference, the path is CLEARLY still to the old dll and causes the same error to occur. This is happening with several other DLLs as well.

Does anyone know of a solution to this issue?

Answer 1

Assemblies like PresentationCore, System.Data and so on.

I hate to answer a question without seeing the error message. But this secondary evidence is enough to answer the question. First off, this is not an error, it is a warning. It looks like this:

warning CS1607: Assembly generation -- Referenced assembly 'System.Data.dll' targets a different processor

You'll also see one for mscorlib.dll. And PresentationCore.dll in a WPF project. What goes on here is that these assemblies are special, they are mixed-mode assemblies. In other words, they contain both native code and managed code. The native code is the trouble-maker, such an assembly can only be used in a project that targets the right processor flavor. If you mix it up then you get a BadImageFormatException at runtime.

This is not a real problem with .NET assemblies, your machine actually has two versions of these DLLs stored in the GAC. One that will be used if your program runs in 32-bit mode and another that is used in 64-bit mode. The CLR automatically picks the right one.

However, there is only one version of the reference assembly, the one that's stored in c:\windows\microsoft.net and that you pass to the compiler to read the metadata from. It is always the x86 version, there's no other one so don't bother looking for it. Again, this is not a problem, only the metadata of a reference assembly is used by the compiler, it doesn't execute any of its code. And the metadata does not depend on the bit-ness of the assembly.

Nevertheless, this all might be a problem if you create your own mixed-mode assembly. You can easily overlook the need to provide two versions. So what the compiler is fretting about is that it sees that you asked for an AnyCPU or x64 build of your project. But detects that the reference assembly can only work when you target x86. So it squeaks at you a bit, just a gentle reminder that there's some evidence that you're getting it wrong and that your program might fall over on a BadImageFormatException when you run it. It doesn't otherwise treat a framework reference assembly any different from your own reference assembly.

So, feature, not a bug. Just a warning that doesn't otherwise prevents your program from building. You can safely ignore the warning since you know that .NET has the right assembly available in the GAC at runtime. Notable is that .NET 4.0 doesn't have this problem, it uses very different reference assemblies that don't have the ILONLY metadata flag turned off.

Answer 2

Odd behavior. Turning "Generate serialization assembly" off under Build in project properties makes the project build just fine in release mode. Looking at this link reveals that this setting has to do with XML Serialization, which we don't even use in our entire solution.

Very weird. Still looking for an explanation for this question and behavior here.