如果您正在使用p / invoke，则需要确保具有64位版本的DLL可用。如果您调用MS提供的DLL（例如kernel32），则这不是问题，因为它们在32位和64位平台上具有相同的名称（奇怪，我知道），因此您的64位应用程序将隐式链接到正确的版本。但是，如果您使用第三方DLL，并且您的64位应用程序尝试链接到32位DLL，则会出现运行时异常。

这也意味着，如果您正在使用进程内的COM对象，您将会遇到问题。64位应用程序可以调用一个32位的进程外COM对象（反之亦然），因为您正在跨进程边界移动，COM会替您处理编组。

除此之外，框架会为您处理大部分事情。您实际上不必担心指针大小，而clr类型具有明确的大小（int始终为32位，长始终为64位）。在纯净的.NET世界中，您没有什么需要担心的。当您开始走出沙盒时，您就必须更加小心。

有两种情况下考虑64位的可能性可能是有趣的：

1. you need to consider containers that have more than 2^31 elements. The standard array .Length property returns Int32, and is thus not capable of representing large arrays - which you can t create in a 32-bit VM anyway. In a 64-bit VM, you should use LongLength instead (unless you know that you have less than 2^31 elements). Unfortunately, many standard collection classes don t seem to support large numbers of elements at all.
2. you can use the long type with fewer concerns about performance: in the 64-bit version, a long fits into a register, whereas in the 32-bit version, the JIT code will need multiple machine instructions for a single long operation.