在VS2012（和以前的版本...）中，您可以在構建項目時指定目標平臺。不過，我的理解是，C＃被「編譯」爲CIL，然後在主機系統上運行時編譯JIT。在編譯c＃應用程序時設置平臺有什麼區別嗎？
這是否意味着只有指定目標平臺的原因是故意限制用戶在某些體系結構上運行軟件或強制應用程序在64位機器上以32位運行？我看不出這是爲了處理優化問題，因爲我猜想發生在CIL - > Native階段，這發生在主機體系結構的Just-In-Time上。
This MS Link似乎沒有提供任何其他解釋，我也沒有發現你應該發佈的事實，例如，應該發佈單獨的32/64位版本的相同應用程序 - 似乎合乎邏輯的是，爲「 anycpu「應該運行得很好，再次，優化將在JIT階段應用。
這是否意味着對指定目標平臺的唯一原因是爲了故意在某些平臺上運行的軟件限制用戶或以武力爲32位在64位計算機上運行的應用程序？
是的，如果您使用與託管代碼混合的本機代碼，這是至關重要的。但是，它不會更改在運行時優化的內容。
如果您的代碼是100％託管的，那麼AnyCPU（或新的AnyCPU首選32位）可能沒問題。編譯器優化將是相同的，並且JIT將根據當前正在執行的平臺在運行時進行優化。
，除非你正在執行我找不到任何的事實，你應該例如，發佈同一應用程序
的獨立六十四分之三十二位版本沒有理由這樣做的建議與非託管代碼互操作，在這種情況下，需要單獨的32位和64位DLL。
P/Invoke或「不安全」的東西是否依賴於此設置？ （我想這些可以被認爲不是100％管理..） – 2012-10-08 19:27:34
@pst P/Invoke是違背本地的，所以它很重要（除非你在運行時有一些方法來確保你只打到正確的平臺DLL），但這不是一個優化問題 - 這是一個正確性問題。 –
@pst - 是的。因爲設置此平臺標誌（如果用於負責啓動運行時的條目可執行文件）將導致代碼被加載到32位或64位內存空間中。如果你的p/invoke被寫爲期望指針和其他特定於內存的類型爲32位維度，並且它被加載到64位運行時（反之亦然），那麼事情將會失敗。 – Adam
裏德在這裏有一個很好的答案。不過，我認爲指出這個設置只是DLL中的一個標誌也很重要 - 在大多數情況下，幾乎所有的都沒有影響。運行時加載程序（啓動.NET運行時的本地代碼位）負責查看此標誌，並指示相應版本的.NET運行時啓動。
由於這個原因 - 標誌大多隻在EXE文件上設置時纔有意義 - 並且在設置DLL時不起作用。 例如 - 如果您有一個由32位標記的.NET EXE或any-cpu標記的.NET EXE使用的「32位標記的.NET DLL」，並且您運行EXE一臺64位機器 - 然後加載器將啓動64位運行時。當加載32位DLL時，已經太晚了 - 已經選擇了64位運行時，所以你的程序會失敗（我相信這是一個BadImageFormatException，你會收到）。
+1對裏德的回答非常好的補充。是的，你對'BadImageFormatException'錯誤是正確的。 – Icarus
我不知道它是否在VS2012中發生了變化，但是在VS2010下以64位模式調試應用程序時，「編輯和繼續」功能不起作用。 – David
@Davis：它沒有。 （但您現在可以使用E＆C編輯包含匿名方法或lambda表達式的方法體，減去它們出現的實際語句） –