我们在64位机器上测试时一直在做32位构建。为了在我们的应用程序中利用机器的强大功能，我们计划为我们的C＃/ .NET 4.0代码库创建64位版本。我们从来没有在过去所做的，并没有测试它尚未虽然它看起来很简单，我们想了解以下信息：从32位移植到64位版本
在简单的情况下，将C＃代码从32位移动到64位只是更改构建设置的问题。安全的C＃代码在64位体系结构上执行的方式与在32位上执行的方式相同。
实际上，您可能会遇到几个问题。下面是一些看出来：
请问你的C＃代码包含不安全的代码？
不安全代码可以操纵指针，并且因此它可以在该假定32位指针的方式被写入。要了解您的项目是否包含不安全的代码，您可以在代码库中搜索“不安全”关键字。
你使用P/Invoke吗？
如果您使用P/Invoke调用本机代码，CLR运行时现在将查找64位DLL而不是32位DLL。如果在运行时找不到64位DLL，你会得到一个异常（“BadImageFormatException”或类似的东西）
你可以在你的代码库中搜索“DllImport”来查看你是否使用P/Invoke。
您的项目是否包含脆弱的代码？
你迁移到64位的项目后，您就可以使用不同版本刚刚在实时（JIT）编译器。与X86 JIT相比，X64 JIT编译器执行更积极的优化。结果，一些错误地编写（通常是多线程）的代码碰巧在X86中工作，最终可能会破坏X64。
你使用像编组，系列化和COM互操作某些功能？
所有这些功能的用法可能需要在64位版本中修改。在代码中搜索的一些关键字包括“Marshal”，“StructLayout”，“FieldOffset”，“BinaryFormatter”和“Com”。
还检查了该白皮书，进一步讨论迁移32位托管代码为64位：http://msdn.microsoft.com/en-us/library/ms973190.aspx
为实用，可操作的提示提高投票权！ – 2012-03-15 22:32:52
您需要了解的另一件事：确保您使用的所有外部dll都具有64位版本。如果引用32位dll，则无法简单构建解决方案。 – Gilthans 2014-06-21 09:34:12
如果您只使用安全托管代码，并且没有第三方DLL，那么您应该期待足够的迁移。
你做想要测试一切，因为通常测试一个产品是一个好主意，一旦它发生了如此重大的变化。你可能会发现一些非常奇怪的事件在64位上失败。
是的，你需要确保你把所有的DLL的64位版本你参考。不，依靠你的32位测试绝对不安全！ （您已经知道了吧？）
我们几年前移植我们的系统为64位，由几件事情感到惊讶：
一些unexpe的例子cted和棘手的问题...
我们的系统包括一个Visual Studio项目向导。 Visual Studio只有32位，但我们的客户可能仍然希望定位到64位机器。所以我们的x86安装程序必须包含我们的x64程序集。通常没问题 - 安装程序发现我们在x86项目中包含了x64文件，发出警告，但仍在继续。但是其中一个程序集包含混合托管/非托管代码，我们的安装程序无法处理该代码。 （我们当时正在使用Visual Studio安装程序，但自那时起我们一直在成长。）因此，我们编写了一个工具，对64位DLL进行十六进制编码并将其写入文本文件，将该文件包含在安装程序中项目，然后有一个自定义安装程序步骤，逆转编码并恢复DLL。
我们的项目向导依赖于一些COM DLL，它们必须在32位注册表中注册，因为Visual Studio是32位的。但在x64上，我们的安装程序以64位运行，因此会调用64位regsvr32.exe，它将DLL注册到错误的位置。所以我们编写了一个在32位注册表中注册DLL的64位工具。
恰巧我们的向导需要知道我们产品的安装位置。所以我们的安装程序将这些信息写入注册表。但在x64上，安装程序以64位运行并将该信息写入64位注册表，但我们的向导以32位运行在Visual Studio中，因此无法读取注册表的这一部分。所以我们再一次写了一个特殊的工具让安装程序将信息写入注册表的两端。
这些问题可能听起来不那么糟糕。毕竟，解决方案非常整齐，非常小巧。但考虑一下：我们的系统是混合托管/非托管COM/C++和C＃，第三方库如Boost，Apache HTTPd和OpenSSL，所有这些都必须重新编译。我原本以为这是很难的部分，但只花了两天的时间来移植代码的相关部分并让项目编译。然后花了整整一周的时间来了解和解决我上面描述的问题。话虽如此，但整个港口只用了一周半的时间，我仍感到非常惊喜。
一个离别的想法......你说你想利用你的64位机器的力量。那是什么意思？非常粗略地说，除非你需要访问超过2GB的RAM，否则你将无法从64位运行中获益。
谢谢Ciaran。你的回答与伊戈尔的回应相结合。 是的，我知道我们必须再次测试64位，但我只是希望有人能够改变我的想法:) – Aziz 2012-03-16 05:17:13
关于64位的力量，我明白，从内存查找术语来说，它增加了容量的RAM。它也与64位的事实有关，我们得到更宽的寄存器和更快的总线尺寸，这意味着处理器必须执行较少的时间存储和查找来自存储器的数据，其更有可能更接近处理器寄存器，缓存。 这来自我的理解是，32位软件无法在64位机器上使用这些功能。 – Aziz 2012-03-16 05:26:21
对不起，我不能告诉你不要打扰测试！听起来你已经考虑过除了“更多更好”之外的优点。我当然不是专家，但我已经读过可执行代码因为指针更宽而增长，但高速缓存行大小与32位相同，因此您有更多高速缓存未命中的风险。我不确定这是否正确，因为取消引用指针的指令使用当前指令的32位偏移量，而不是64位绝对地址。我不太了解这个话题，以预测我的系统有什么改进。 – 2012-03-16 06:59:09
不，这不是一个依靠32位功能测试的安全策略！你的问题是好的和相关的。我很惊讶地发现我的32位应用程序中的功能行为有显着的不同，可以正常工作。有关更多详细信息，请参阅What causes significant loss of FP precision when compiling for 64-bit?（注意：负面评级是由于格式不正确，我改变了）
可能重复的[C＃开发的64位东西]（http://stackoverflow.com/questions/ 1889941/64-bit-stuff-for-c-sharp-development） – 2012-03-15 22:49:01
如果您的应用程序由纯粹的.NET程序集组成，那么您可能会考虑将目标设定为AnyCPU而不是32位或64位。然后，您的应用程序将在目标机器上使用最合适的运行时版本（32位或64位）。但是下面答案中的测试评论依然存在。 – Glenn 2012-03-16 02:47:57