最近在做的專案涉及到32位以及64位的問題，查看了很多資料，大部分都是如下這樣的解釋。

一、在VisualStudio中，編譯設定有如下選項：

    x86： 將程式集編譯為由相容 x86 的 32 位公共語言執行庫執行。

x64： 將程式集編譯為由支援 AMD64 或 EM64T 指令集的計算機上的 64 位公共語言執行庫執行。

anycpu：（預設值）將程式集編譯為在任意平臺上執行。

Itanium： 將程式集編譯為由採用 Itanium 處理器的計算機上的 64 位公共語言執行庫執行。

    二、具體行為如下：

    1）在 64 位 Windows 作業系統上：

用 x86 編譯的程式集將在 WOW64 下執行的 32 位 CLR 上執行。

用 x64 編譯的程式集將在 64 位 CLR 上執行。

用 anycpu 編譯的可執行檔案將在 64 位 CLR 上執行。

用 anycpu 編譯的 DLL 將在與載入它的程序相同的 CLR 上執行。

    2）在 32 位 Windows 作業系統上：

用 x86或anycpu 編譯的程式集將在 32 位 CLR 上執行。

用 x64 編譯的程式集無法執行。

 我們重點關注Any CPU這一種方式，因為這種方式是最靈活的一種，在32位下，EXE將以32位執行，而在64位下，EXE將以64位執行。於是我用dumpbin工具檢視和驗證，我的機器是win7 64位，在使用anycpu進行編譯時，exe確實為64位格式，截圖如下：

x86編譯後，截圖如下：

anycpu編譯如下：(勾選首選32位)

anycpu編譯如下：(未勾選首選32位)

通過這種方式發現，和我們預期的結果不一樣，按理說最後一個應該是64位的，然後我們看到的結果為32位，為什麼會這樣呢？難道是dumpbin不適用於c#,但是為什麼x64,x86編譯的方式又是正確的，或者anycpu這種的描述是錯誤的，永遠不會生成64位？一直沒有找到合適的解答，最後，終於找到合適的解釋了，那就是在x86，x64這2種編譯方式用dumpbin是沒問題的，對於anycpy，系統做了特殊處理，因此dumpbin可能不適合了，那我們怎麼來判斷是32位還是64位呢？我又找到另外的一種方法。

1、根據IntPtr.Size來判斷，如果值為4則是32位，如果為8則是64位，所有.NET版本都支援。

if (IntPtr.Size == 4)
{
    // 32-bit
}
else if (IntPtr.Size == 8)
{
    // 64-bit
}
else
{
    //未來肯定有
}

2、如果.NET的版本是4.0或之後，則可以用Environment.Is64BitProcess來判斷當前程序是否是64位的。

if(Environment.Is64BitProcess)
{
   //64-bit
}
else
{
   //估計很長一段時間內都是32-bit
}

於是用這種方法對anycpu編譯的exe再次進行測試，發現果然是正確的，在我的機器上(win7 64位)anycpu,勾選“首選32位”生成的32位程式，未勾選“首選32位”，則生成的64位。我的疑惑終於得到了解答。

因此，在使用什麼方式編譯時，給大家都建議如下：

dll使用anycpu選項編譯，不勾選“首選32位”,exe如果想生成位64位，則用x64,如果想生成32位，則用x86，如果想跟隨系統變化，則位anycpu。