How do I fix the Visual Studio compile error, “mis

Question

I'm new to project configuration in Visual Studio 2010, but I've done some research and still can't quite figure this issue out. I have a Visual Studio solution with a C++ DLL referencing the C# DLL. The C# DLL references a few other DLLs, some within my project and some external. When I try to compile the C++ DLL, I get this warning:

warning MSB3270: There was a mismatch between the processor architecture of the project being build "MSIL" and the processor architecture of the reference "[internal C# dll]", "x86".

It tells me to go to Configuration Manager to align my architectures. The C# DLL is set up with platform target x86. If I try to change this to something else, like Any CPU, it complains because one of the external DLLs it depends on has platform target x86.

When I look at Configuration Manager it shows the Platform for my C# DLL as x86 and for my C++ project as Win32. This seems like the right setup; surely I don't want the project for my C++ project to have platform set to x64, which is the only other option presented.

What am I doing wrong here?

Answer 1

For C# projects, the target of x86 does what it sounds like. It says that this assembly only supports x86 architectures. Likewise for x64. Any CPU on the other hand says that I don't care which architecture, I support both. So, the next 2 questions are (1) what is the configuration of the executable that uses these dlls? and (2) what is the bitness of your OS/Computer? The reason I ask is because if your executable is compiled to run in 64-bit, then it NEEDS all dependencies to be able to run in 64-bit mode as well. Your Any CPU assembly should be able to be loaded, but perhaps it is referencing some other dependency that is only capable of running in x86 configuration. Check all dependencies and dependencies-of-dependencies to make sure everything is either "Any CPU" or "x64" if you plan to run the executable in 64-bit mode. Otherwise, you'll have issues.

In many ways, Visual Studio does not make compiling a mixture of Any CPU and various architecture dependent assemblies easy. It is doable, but it often requires that an assembly that would otherwise be "Any CPU" to have to be compiled separately for x86 and x64 because some dependency-of-a-dependency somewhere has two versions.

Answer 2

I had similar problem it was caused by MS UNIT Test DLL. My WPF application was compiled as x86 but unit test DLL (referenced EXE file) as "Any CPU". I changed unit test DLL to be compiled for x86 (same as EXE) and it was resovled.

Answer 3

I've had a similar problem before, specifically when adding a test solution to an existing x64 solution, like SharePoint. In my case, it seems to have to do with the fact that certain project templates are added as certain platforms by default.

Here's the solution that often works for me: set everything to the correct platform in the Configuration Manager (the active configuration drop-down, says Debug normally, is a good way to get to it) and project platform (in project properties), then build, then set everything back to AnyCPU. Sometimes I have to remove and re-add some dependencies (DLLs in each project's Properties) and sometimes the "Run tests in 32 bit or 64 bit process" (double-click Local.testsettings and go to Hosts) has to be changed.

It seems to me that this is just setting something then setting it back, but there's probably more going on behind the scenes that I'm not seeing. It's worked fairly consistently for me in the past though.

Answer 4

You may also get this warning for MS Fakes assemblies which isn't as easy to resolve since the f.csproj is build on command. Luckily the Fakes xml allows you to add it in there.

Answer 5

I was getting the same warning i did this:

1. unload project
2. edit project properties i.e .csproj

3. add the following tag:

   <PropertyGroup>
       <ResolveAssemblyWarnOrErrorOnTargetArchitectureMismatch>
           None
       </ResolveAssemblyWarnOrErrorOnTargetArchitectureMismatch>
   </PropertyGroup>
   

4. Reload the project

Answer 6

A good rule of thumb is "open DLLs, closed EXEs", that is:

• EXE targets the OS, by specifying x86 or x64.
• DLLs are left open (i.e., AnyCPU) so they can be instantiated within a 32-bit or a 64-bit process.

When you build an EXE as AnyCPU, all you're doing is deferring the decision on what process bitness to use to the OS, which will JIT the EXE to its liking. That is, an x64 OS will create a 64-bit process, an x86 OS will create an 32-bit process.

Building DLLs as AnyCPU makes them compatible to either process.

For more on the subtleties of assembly loading, see here. The executive summary reads something like:

• AnyCPU – loads as x64 or x86 assembly, depending on the invoking process
• x86 – loads as x86 assembly; will not load from an x64 process
• x64 – loads as x64 assembly; will not load from an x86 process