我們在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