想象一下一个纯粹的.NET应用程序，它不使用COM组件或PInvoke。如果目标系统是32位还是64位，这是否重要？
在32位或64位系统中，.NET有哪些区别？
5
- Jader Dias
1
重复：https://dev59.com/OnVC5IYBdhLWcg3w7Vxq - Mauricio Scheffer
3个回答
7
如果应用程序目标为 AnyCPU，运行时行为将不同，特别是内存使用和限制。
在 64 位系统上，不会有相同的 32 位内存限制（理论上最大 2GB 内存，但实际上为 1.2-1.6GB）。然而，所有对象引用都是两倍大，因此 64 位系统将使用更多内存。
此外，64 位系统通常具有额外的寄存器等，因此有时性能可能会略有提高。但这是平台特定的。
如果应用程序目标为 x86，则将在 WoW64 下运行，并且几乎与在 32 位系统中运行的方式相同。
在 64 位系统上，不会有相同的 32 位内存限制（理论上最大 2GB 内存，但实际上为 1.2-1.6GB）。然而，所有对象引用都是两倍大，因此 64 位系统将使用更多内存。
此外，64 位系统通常具有额外的寄存器等，因此有时性能可能会略有提高。但这是平台特定的。
如果应用程序目标为 x86，则将在 WoW64 下运行，并且几乎与在 32 位系统中运行的方式相同。
- Reed Copsey
5
假设没有COM组件、P/Invoke等安全代码，语义上不应该有任何差异，但性能可能会受到影响。考虑：在64位下占用更多的内存，但引用更大。并非完全得利或者完全得失。
无论如何，这里有一些有用的参考资料：
请参见MSDN：从32位托管代码迁移到64位。引用：
“[...] 考虑一个.NET应用程序，它是100%类型安全代码。在这种情况下，你可以将你在32位机器上运行的.NET可执行文件移动到64位系统，并成功运行。为什么会这样呢？因为这个程序集是100%类型安全的，我们知道它没有依赖于本地代码或COM对象，并且没有'unsafe'代码，这意味着应用程序完全在CLR的控制下运行。CLR保证，尽管即时（JIT）编译的二进制代码在32位和64位之间生成时将是不同的，但执行的代码将是语义上相同的。[...]”
无论如何，这里有一些有用的参考资料：
请参见MSDN：从32位托管代码迁移到64位。引用：
“[...] 考虑一个.NET应用程序，它是100%类型安全代码。在这种情况下，你可以将你在32位机器上运行的.NET可执行文件移动到64位系统，并成功运行。为什么会这样呢？因为这个程序集是100%类型安全的，我们知道它没有依赖于本地代码或COM对象，并且没有'unsafe'代码，这意味着应用程序完全在CLR的控制下运行。CLR保证，尽管即时（JIT）编译的二进制代码在32位和64位之间生成时将是不同的，但执行的代码将是语义上相同的。[...]”
- Chris W. Rea
1
1理论上，应用程序将运行相同，但是在实践中，32位和64位框架之间的实现存在差异，以及不同的错误。虽然不常见，但确实会发生。在过去的两个月中，我遇到了至少3种情况，在x64系统上针对x86和针对AnyCPU时，相同的MSIL的行为有所不同。 - Joe Kuemerle
4
除了Reed Copsey所列出的那些情况，另一种可能会有影响的方式是，如果您的“纯净”应用程序恰好使用System.IntPtr结构体进行某些操作，或者它使用不安全代码（这与P / Invoke不同）和指针算术运算。
另一个需要注意的重要问题是调用System.Runtime.InteropServices.Marshal类中的几乎任何内容。在那里有各种绝妙的方法可以让您自食其果（当然，在需要时非常有用）。
另一个需要注意的重要问题是调用System.Runtime.InteropServices.Marshal类中的几乎任何内容。在那里有各种绝妙的方法可以让您自食其果（当然，在需要时非常有用）。
- Doug McClean
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接