在VS2012(以及之前的版本......)中,您可以在构建项目时指定目标平台。但我的理解是,C#被“编译”到CIL,然后在主机系统上运行时进行JIT编译。
这是否意味着指定目标平台的唯一原因是故意限制用户在某些体系结构上运行软件或强制应用程序在64位计算机上以32位运行?我无法看到它会与优化有关,因为我猜这种情况发生在CIL - > Native阶段,它在主机架构上发生了即时?
This MS Link似乎没有提供任何替代解释,我没有找到任何关于你应该,例如,释放相同应用程序的32/64位版本的事实的建议 - 这似乎是合乎逻辑的东西为“anycpu”编译的应该也应该运行,并且再次优化将在JIT阶段应用。
答案 0 :(得分:16)
这是否意味着指定目标平台的唯一原因是故意限制用户在某些体系结构上运行软件或强制应用程序在64位计算机上以32位运行?
是的,如果您使用与托管代码混合的本机代码,这一点至关重要。但是,它不会改变在运行时优化的内容。
如果您的代码是100%管理的,那么AnyCPU(或新的AnyCPU首选32位)可能没问题。编译器优化将是相同的,JIT将在运行时基于当前执行平台进行优化。
我发现没有任何关于您应该发布相同应用程序的32/64位版本的事实
除非您使用非托管代码执行互操作,否则没有理由这样做,在这种情况下,需要单独的32位和64位DLL。
答案 1 :(得分:12)
里德在这里有一个很好的答案。但是,我认为指出这个设置只是DLL中的一个标志也很重要 - 在大多数情况下几乎没有任何影响。运行时加载程序(启动.NET运行时的本机代码位)负责查看此标志,并指示要启动的.NET运行时的相应版本。
由于这个原因 - 该标志主要仅在EXE文件上设置时才起作用 - 并且在DLL上设置时无效。 例如 - 如果你有一个'32位标记的.NET DLL',它由64位标记的.NET EXE或任何带有标记的.NET EXE使用,并且你运行EXE 64位机器 - 然后加载器将启动64位运行时。当需要加载32位DLL时,为时已晚 - 已经选择了64位运行时,因此您的程序将失败(我相信这将是您将收到的BadImageFormatException)。