处理器体系结构问题(x86 与任何 CPU)
本文关键字：任何 CPU x86 体系结构 问题 处理器 | 更新日期: 2023-09-27 18:31:23
我有一个为 x86 构建的库。在引用程序集的"任何 cpu"中编译 .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库。
Project A（Windows Service，AnyCpu）-->CommonLibrary（AnyCPU）-->UtilityLibrary（x86）
项目 B（WinForms， AnyCpu）-->CommonLibrary（AnyCPU）-->UtilityLibrary（x86）
在项目 A 中，我在使用 UtilityLibrary 时遇到运行时错误。但不是来自项目B。一旦在"任何CPU"中构建了实用程序库，或者项目 A 在 x86 中构建，项目 A 中的运行时错误就会得到解决，所以我知道它与此有关。
我的问题是：在哪些情况下会发生使用特定于体系结构的库的运行时错误？
实用程序库是最近软件版本的一部分，公共库是 API 也是软件版本的一部分。我试图确定这样做的后果。在未来的版本中，实用程序库将为AnyCpu构建，因为没有理由将其设置为X86。
如果在 64 位计算机上运行，则标准行为是在 64 位进程而不是 32 位进程中运行AnyCPU可执行文件。标记为 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 位进程运行。
Visual Studio 2013 的默认值是"Any CPU"和"Preferred 32-bit"，适用于新的 Windows 窗体和 Windows Service 项目。（在更新 3 上测试。从旧版本的 Visual Studio 升级的项目可能具有不同的设置。这也许可以解释为什么 Project B 可以工作而 Project A 不起作用，如果 Project B 是在旧版本上创建的，或者有人更改了该设置。
详细检查构建设置。除了体系结构选择之外，还有一个"首选 32 位"复选框。默认情况下，Windows 客户端应用程序选中此复选框，这就是 WinForms 应用程序以 32 位运行并正常工作的原因。很可能您的 Windows 服务没有检查该内容，因此以 64 位运行。