从32位版本迁移到64位版本

时间:2012-03-15 21:13:13

标签: c# 64-bit

我们在64位计算机上进行测试时一直在进行32位构建。为了充分利用机器的功能,我们计划为C#/ .NET 4.0代码库进行64位构建。我们过去从未这样做过,还没有测试过,虽然看起来很简单但我们想了解以下内容:

  • 在迁移过程中我们需要采取哪些必要步骤?
  • 在此次迁移过程中,我们可以预期会出现什么问题?坦率地说,我不确定我们可能面临任何打嗝?就像我们的代码引用了32位版本被引用的底层DLL一样?我们需要更新所有参考文献吗?同样,我们在这里没有太多见解,所以这个具体问题可能无关紧要。但我们想了解任何可能妨碍顺利过渡的问题。
  • 我们在32位上进行了所有功能测试。我们可能没有太多时间在64位上进行严格的测试?依靠我们的32位功能测试是一种安全的策略吗?

4 个答案:

答案 0 :(得分:10)

在简单的情况下,将C#代码从32位移动到64位只需要更改构建设置。安全C#代码在64位体系结构上执行的方式与在32位上执行的方式相同。

在实践中,您可能遇到几个问题。以下是一些值得关注的内容:

  • 您的C#代码是否包含不安全的代码?

    不安全的代码可以操作指针,因此它可以采用假设32位指针的方式编写。要确定您的项目是否包含不安全的代码,您可以在代码库中搜索“不安全”关键字。

  • 您使用的是P / Invoke吗?

    如果使用P / Invoke调用本机代码,CLR运行时现在将查找64位DLL而不是32位DLL。如果在运行时找不到64位DLL,您将获得异常(“BadImageFormatException”或类似的东西)

    您可以在代码库中搜索“DllImport”以查看您是否正在使用P / Invoke。

  • 您的项目是否包含脆弱的代码?

    将项目移动到64位后,您将使用不同版本的Just-in-Time(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

答案 1 :(得分:4)

是的,您需要确保您拥有所引用的所有DLL的64位版本。不,依靠32位测试绝对不安全! (你已经知道了,对吗?)

几年前我们将系统移植到64位,并对一些事情感到惊讶:

  • 一般来说,港口比我们预期的要容易得多
  • 在最奇怪的地方出现了最困难的问题,我们认为这些地方很简单
  • 后续版本无故障

一些意外和棘手问题的例子......

我们的系统包括一个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注册在错误的位置。因此,我们编写了一个64位工具,用于在32位注册表中注册DLL。

我们的向导需要知道我们的产品安装位置。所以我们的安装程序将该信息写入注册表。但是在x64上,安装程序以64位运行并将该信息写入64位注册表,但我们的向导以32位运行在Visual Studio中,因此无法读取该部分注册表。因此,我们再次编写一个特殊工具,让安装程序将信息写入注册表的两端。

这些问题听起来可能不是那么糟糕。毕竟,解决方案非常整洁,非常小。但请考虑一下:我们的系统是混合托管/非托管COM / C ++和C#,以及第三方库,如Boost,Apache HTTPd和OpenSSL,所有这些都必须重新编译。我曾预料到这将是困难的部分,但只需要两天的时间来移植相关的代码并让项目进行编译。然后又花了一个星期来理解和解决我上面描述的问题。话虽如此,我仍然非常惊喜地发现整个港口只花了一个半星期。

分手思考......你说你想利用64位机器的强大功能。那是什么意思?粗略地说,除非您需要访问超过2GB的RAM,否则您将无法从64位运行中获得任何好处。

答案 2 :(得分:0)

如果您只使用安全的托管代码,而且没有第三方DLL,那么您应该可以轻松迁移。

想要测试所有东西,因为一旦产品发生如此重大的变化,测试产品通常是个好主意。您可能会发现一些非常奇怪的事件在64位上失败。

答案 3 :(得分:0)

不,依靠32位功能测试不是一种安全的策略!你的问题很好而且相关。我很惊讶地发现我的32位应用程序中功能行为的显着差异正常工作。有关详细信息,请参阅What causes significant loss of FP precision when compiling for 64-bit? (注意:否定评分是由于格式错误导致的,我已更改)