我相信在制作.Net程序时会为我们抽象出体系结构类型(x86与x64)，但是还有其他考虑因素会引起问题吗？

解决方案

谨防秘密地进行win32调用的第三方COM库或者第三方.NET库。那是我们最头疼的地方。

x64将允许我们寻址更多的内存，但是给定相同的代码，它将比x86使用更多的内存。

来自MSDN doco，以及其他注意事项：

In many cases, assemblies will run the same on the 32-bit or 64-bit CLR. Some reasons for a program to behave differently when run by the 64-bit CLR include: 
  
  
  Structs that contain members that
  change size depending on the platform,
  such as any pointer type. 
  Pointer arithmetic that includes
  constant sizes. 
  Incorrect platform invoke or COM
  declarations that use Int32 for
  handles instead of IntPtr. 
  Casting IntPtr to Int32

另外，默认文件位置。

本文有很多不错的问题要注意：
http://osnews.com/story/20330/Windows_x64_Watch_List

就我个人而言，我的老板有一台64位Vista计算机，而我以32位模式编程。我们遇到了以下问题：

• 32位应用程序的注册表被隐藏(某种程度上)到Wow6432Node文件夹中。并非我们用来在注册表中查找路径的所有应用都将在该节点中(例如，SQL Server不会)。
• C：\ Windows文件夹中的SysWow64可能会导致DLL不在所需位置的问题(此问题带有第3方许可组件)。
• 有时，我们需要的文件位于" C：\ Program Files(x86)"中，而不是" C：\ Program Files"中。也很烂

• 在32位平台上，读取和写入64位值不是线程安全的。读取64位值需要执行两项操作，这些操作可能会被上下文切换中断。有关更多信息，请参见Threading.Interlocked.Read上的MSDN文章。
• 也完全同意讲解的答案！ :-)

MSDN提出了一些有关将32位应用程序移植到64位执行环境的问题的论文。

http://msdn.microsoft.com/en-us/library/ms973190.aspx

另外两名博客作者在CLR团队中时曾写过有关64位开发的文章。

• 高拉夫·塞斯(Gaurav Seth)
• 斯潘基

以我的经验，移植Asp.NET应用程序基本上是完美的。在32位计算机和64位计算机上运行，​​除了拥有更多可用内存之外，没有任何问题。发生这种情况的原因是，已经提到的许多问题(注册表，线程等)已由Asp.NET管理，并且我们需要正确修复它们才能在Asp.NET环境中运行。

客户端(Windows窗体)也发生了同样的事情，但是如果我们已经使用某些"不安全"的API获取特殊文件夹或者注册表访问权限，则可能会发生某些问题，正如已经指出的那样。

问候
马西莫