处理器体系结构问题（x86与任何CPU）

Question

I have a library that is built for x86. When compiling .net projects in "any cpu" that is referencing the assembly, I get the following compiler warning:

"There was a mismatch between the processor architecture of the project being built "MSIL" and
the processor architecture of the reference "xxx", processorArchitecture=MSIL", "x86". This
mismatch may cause runtime failures. Please consider changing the targeted processor
achitecture of your project through the Configuration Manager..."

I have two projects. Project A and B. Both is .net c# visual studio (2013) projects. Project A is a windows service, project B is a simple windows forms application. They both use a common library (also any cpu) that again (sometimes) use the x86 library.

Project A(Windows Service,AnyCpu)-->CommonLibrary(AnyCPU)-->UtilityLibrary(x86)

Project B(WinForms, AnyCpu)-->CommonLibrary(AnyCPU)-->UtilityLibrary(x86)

In Project A, I get a runtime error when using the UtilityLibrary. But not from Project B. The runtime error in Project A is resolved once the UtilityLibrary is built in "Any Cpu", or Project A is built in x86, so i know it is related to this.

My question is: In which cases does the runtime errors of utilizing architecture specific libraries occur?

The UtilityLibrary is a part for a recent software release, and the CommonLibrary is an API also part of the software release. I am trying to determine the consequences of this. In future releases, the UtilityLibrary will be built for AnyCpu, as there is no reason for this to be X86.

Answer 1

If running on a 64-bit machine, the standard behaviour is to run an AnyCPU executable in a 64-bit process, rather than a 32-bit process. An assembly marked x86 will fail to load in a 64-bit process. The .NET Framework assumes that there's something in there which is architecture-specific, and that it's better to report the problem up-front, rather than crash or do the wrong thing when an architecture-specific operation is performed.

The build tools are warning you that this will happen if you do run it in that scenario.

If you're sure that the UtilityLibrary doesn't contain any processor-specific code or depend on anything that's only available as a 32-bit library (eg the JET database engine), you can avoid a recompile by changing the headers, using CorFlags.exe . The command you need is:

corflags <path-to-assembly> /32bit-

In .NET 4.5, a new option became available: 'Prefer 32-bit'. For the C# compiler, this option is /platform:anycpu32bitpreferred . An executable marked with this value will run in a 32-bit process on a 64-bit machine, if the 32-bit runtime is available. In Windows 7/Server 2008 R2 and later, it's actually possible to remove the WOW64 layer that allows 32-bit programs to run. If you marked the executable as 'x86', it wouldn't run at all without WOW64, but if you used Any CPU + Prefer 32-bit, it would run as a 64-bit process instead.

The defaults for Visual Studio 2013 are 'Any CPU' and 'Prefer 32-bit', for new Windows Forms and Windows Service projects. (Tested on Update 3.) Projects upgraded from older versions of Visual Studio may have different settings. This might explain why ProjectB works while ProjectA doesn't, if ProjectB was created on an older version, or if someone has changed that setting.

Answer 2

Check you build settings in detail. In addition to the architecture choice, there is a "prefere 32 bit" checkbox. This checkbox is checked by default for windows client applications, that's why your WinForms application runs in 32 bit and works. Most likely your Windows Service doesn't have that checked and therefore runs in 64 bit.