我有一个为x86构建的库。在＆＃34;任何cpu＆＃34;中编译.net项目时。在引用程序集时，我得到以下编译器警告：
"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..."
我有两个项目。项目A和B.两者都是.net c＃visual studio（2013）项目。 项目A是一个Windows服务，项目B是一个简单的Windows窗体应用程序。它们都使用公共库（也是任何cpu），它再次（有时）使用x86库。
项目A（Windows服务，AnyCpu） - ＆gt; CommonLibrary（AnyCPU） - ＆gt; UtilityLibrary（x86）
项目B（WinForms，AnyCpu） - ＆gt; CommonLibrary（AnyCPU） - ＆gt; UtilityLibrary（x86）
在Project A中，使用UtilityLibrary时出现运行时错误。但不是来自项目B. 一旦构建了UtilityLibrary，就会解决项目A中的运行时错误。任何Cpu＆＃34;或项目A都是在x86中构建的，所以我知道它与此相关。
我的问题是：在哪些情况下，使用体系结构特定库的运行时错误会发生？
UtilityLibrary是最近发布的软件的一部分，CommonLibrary也是API的一部分。我试图确定这种后果。 在将来的版本中，UtilityLibrary将为AnyCpu构建，因为没有理由将其作为X86。
答案 0 :(得分：3)
如果在64位计算机上运行，标准行为是在64位进程中运行AnyCPU可执行文件，而不是32位进程。标记为x86的程序集将无法在64位进程中加载。 .NET Framework假定那里有一些特定于体系结构的东西，并且最好在事先报告问题，而不是在执行特定于体系结构的操作时崩溃或做错事。
构建工具警告您，如果您在该场景中运行它，就会发生这种情况。
如果您确定UtilityLibrary不包含任何特定于处理器的代码或依赖于仅作为32位库提供的任何内容（例如JET数据库引擎），则可以通过更改标题来避免重新编译，使用CorFlags.exe。您需要的命令是：
corflags <path-to-assembly> /32bit-
在.NET 4.5中，有一个新选项可用：'首选32位'。对于C＃编译器，此选项为/platform:anycpu32bitpreferred。如果32位运行时可用，则使用此值标记的可执行文件将在64位计算机上以32位进程运行。在Windows 7 / Server 2008 R2及更高版本中，实际上可以删除允许运行32位程序的WOW64层。如果您将可执行文件标记为'x86'，则在没有WOW64的情况下它将无法运行，但如果您使用任何CPU +首选32位，它将作为64位进程运行。
对于新的Windows窗体和Windows服务项目，Visual Studio 2013的默认值为“任何CPU”和“首选32位”。 （在更新3上测试。）从旧版本的Visual Studio升级的项目可能具有不同的设置。这可能解释了为什么ProjectB不工作，ProjectA不工作，如果ProjectB是在旧版本上创建的，或者有人更改了该设置。
答案 1 :(得分：1)
详细检查您的构建设置。除了架构选择之外，还有一个“优先32位”复选框。对于Windows客户端应用程序，默认情况下会选中此复选框，这就是您的WinForms应用程序以32位运行并运行的原因。很可能你的Windows服务没有经过检查，因此以64位运行。