编译 c# 应用程序时设置平台有什么不同吗？答案

【问题标题】：Does setting the platform when compiling a c# application make any difference?编译 c# 应用程序时设置平台有什么不同吗？
【发布时间】：2012-09-29 02:00:34
【问题描述】：

在VS2012（以及以前的版本...）中，您可以在构建项目时指定目标平台。不过，我的理解是，C# 被“编译”为 CIL，然后在主机系统上运行时被 JIT 编译。

这是否意味着指定目标平台的唯一原因是故意限制用户在某些架构上运行软件或强制应用程序在 64 位计算机上以 32 位运行？我看不出这与优化有关，因为我猜这发生在 CIL-->Native 阶段，这发生在主机架构上的 Just-In-Time 阶段？

This MS Link 似乎没有提供任何替代解释，我找不到任何建议，例如，您应该发布同一应用程序的单独 32 / 64 位版本 - 为某些东西编译似乎是合乎逻辑的“anycpu”应该也能正常运行，并且优化将再次应用于 JIT 阶段。

【问题讨论】：

不知道VS2012有没有变化，但是VS2010下64位模式下调试应用时“编辑继续”功能不起作用。
@Davis：没有。（但您现在可以使用 E&C 编辑包含匿名方法或 lambda 的方法主体，减去它们出现的实际语句）

标签： c# optimization jit compiler-optimization cil

【解决方案1】：

这是否意味着指定目标平台的唯一原因是故意限制用户在某些架构上运行软件或强制应用程序在 64 位机器上以 32 位运行？

是的，如果您将本机代码与托管代码混合使用，这一点至关重要。但是，它不会改变运行时优化的内容。

如果您的代码是 100% 托管的，那么 AnyCPU（或新的 AnyCPU Prefer 32-Bit）可能没问题。编译器优化是一样的，JIT会在运行时根据当前执行平台进行优化。

我找不到任何建议，例如，您应该发布同一应用程序的单独 32 / 64 位版本

除非您与非托管代码执行互操作，否则没有理由这样做，在这种情况下，这将需要单独的 32 位和 64 位 DLL。

【讨论】：

P/Invoke 或“不安全”的东西是否取决于此设置？（我想那些可以被认为不是 100% 管理的......）
@pst P/Invoke 与本机背道而驰，因此它在那里很重要（除非您在运行时有某种方法来确保您只访问正确的平台 DLL），但这不是优化问题 - 这是一个正确性问题。
@pst - 是的。因为设置此平台标志（如果在负责启动运行时的入口可执行文件上使用）将导致代码被加载到 32 位或 64 位内存空间中。如果您的 p/invoke 被写入期望指针和其他内存特定类型为 32 位维度，并且它被加载到 64 位运行时（反之亦然），那么事情将会失败。
我有另一个有效的（尽管是次要的）理由来解释你为什么要限制平台。在某些情况下，与 64 位相比，在 32 位中运行可以减少内存消耗，因为所有对象引用只有 4 个字节而不是 8 个。如果您知道您永远不会强制使用 32 位，则可以减少程序的内存占用消耗超过 2 GB。
@AllonGuralnek 是的 - 一般来说，除非您需要 64 位，否则 32 位通常会更好。我相信这就是为什么 VS 2012 中的默认设置现在是“AnyCPU Prefer 32-bit”而不仅仅是 AnyCPU。

【解决方案2】：

里德在这里有一个很好的答案。但是，我认为同样重要的是要指出此设置只是 DLL 中的一个标志 - 它几乎在大多数情况下都没有任何影响。运行时加载器（启动 .NET 运行时的那段本地代码）负责查看此标志，并引导适当版本的 .NET 运行时启动。

正因为如此 - 该标志主要只在它设置在 EXE 文件上时才有意义 - 而在 DLL 上设置时没有效果。例如 - 如果您有一个由 64 位标记的 .NET EXE 或任何 cpu 标记的 .NET EXE 使用的“32 位标记的 .NET DLL”，并且您在64 位机器 - 然后加载程序将启动 64 位运行时。当需要加载 32 位 DLL 时，为时已晚 - 已经选择了 64 位运行时，因此您的程序将失败（我相信您将收到 BadImageFormatException）。

【讨论】：

+1 很好地补充了 Reed 的回答。是的，您对BadImageFormatException 错误的看法是正确的。