.NET程序集和CPU架构之间有什么关系？

Question

.NET程序集与“bitness”之间的关系是什么，或恰当地说，CPU架构？我认为.NET程序被编译成CIL（字节码），并且它们可能最终在不同的体系结构中运行，并将自动编译。因此，.NET程序集应该没有“位”。

但现实世界似乎并不那么简单。我在64位计算机上测试程序，并经常在我的程序和另一个.NET库之间遇到奇怪的兼容性问题。所以我的问题是：

• .NET二进制文件能否以某种方式内置CPU架构？
• 在什么条件下/应该发生这种情况？
• 在64位计算机上，哪些事件链导致.NET代码在32位环境中运行？

BTW：这个问题（Differences between 32 and 64-bit .NET (4) applications）及其最佳答案理所当然地认为.NET应用程序有一定的意义。但我认为无法在Visual Studio中设置架构。

Answer 1

您提到的问题将此视为理所当然，因为它确实如此：.NET应用程序专门针对不同的CPU架构而构建（在许多情况下也可以为“混合平台”构建，如果可用的话，它将运行64位否则为32位。

默认情况下，此选项未在Visual Studio中清晰显示，但“解决方案平台”下拉列表可以添加到标准工具栏，默认情况下会与“解决方案配置”下拉列表一起添加。

此外，如果从配置下拉列表中选择“配置管理器”，您将看到当前的平台，并可以编辑解决方案中每个程序集的设置。

具体回答你的三颗子弹：

• 每个.NET二进制文件都内置了CPU架构，即使它是“任何CPU”
• 每次构建都会发生这种情况;它是非选择性的
• 64位计算机将以32位运行.NET程序集，如果：
  • 它是明确构建的x86
  • 调用程序集是x86（如果引用它的程序集是32位，“任何CPU”dll将以32位运行）