1
votes

I have a x64 .NET project. To that project I have added a reference, which I believed to have been built in AnyCPU-mode. The image below shows the output of CORFLAGS for that reference assembly (32BITREQ : 0 -> AnyCPU, right?).

Output of CORFLAGS for my reference Still the compiler gives me the following warning:

There was a mismatch between the processor architecture of the project being built "AMD64" and the processor architecture of the reference "MyReference, Version=2.1.0.0, Culture=neutral", "x86". This mismatch may cause runtime failures. Please consider changing the targeted processor architecture of your project through the Configuration Manager so as to align the processor architectures between your project and references, or take a dependency on references with a processor architecture that matches the targeted processor architecture of your project.

So what's wrong here? Did I interpret the CORFLAGS the wrong way? Or do I need to change something in my VS build configuration?

1
What does your build properties dialog look like? That's a simpler way of understanding it than using CORFLAGS, IMO.Jon Skeet

1 Answers

2
votes

Yes, you interpreted it wrong. Most important signal is ILONLY : 0, that tells you that you have a mixed-mode assembly that contains both IL and machine code. The C++/CLI language is the primary way to create assemblies like that, the native C++ code in the project got compiled to machine code directly.

Then the PE value tells you that this C++ code got compiled to x86 machine code. And the compiler appropriately warns that this assembly isn't usable in your project, it will bomb at runtime with a BadImageFormatException when your program attempts to call the C++ code.

The 32BITREQ bit is not meaningful in this scenario, just "requesting" it isn't good enough, the C++ linker (unhelpfully) leaves it unset.

If you want to use it then you'll have to rebuild it. Add the x64 platform to the project so the C++/CLI compiler will generate 64-bit machine code. That isn't always possible, the C++/CLI might have a dependency on a library that's only available in 32-bit or contain assembly code that's difficult to rewrite. If the assembly isn't yours then you'll have to get on the phone to ask.


There's a small glimmer of hope that this turns out well anyway, note that this is just a compile warning and not an outright error. Your machine might already have the 64-bit version of this assembly available in the GAC, put there by an installer supplied by the assembly owner.

Have a look-see at the content of the GAC, c:\windows\microsoft.net\assembly for .NET 4.0+ assemblies. The GAC_64 subdirectory is the home for mixed-mode assemblies that contain 64-bit machine code. If you see the same assembly there then you're good to go, the CLR will load the assembly from this directory at runtime. Just a small glimmer, this is not common for assemblies that are not part of the .NET Framework. Good luck.