.net平臺支援的有32位、64位以及Any CPU三種編譯模式，這三種編譯模式會導致呼叫該dll時的相容問題。

已知的可正常執行的組合有：

①32位/64位/Any CPU模式的App呼叫Any CPU模式的dll檔案，除了64位App不能在32位系統執行以外，均可

②32位App呼叫32位dll，32位/64位系統均可

③64位App呼叫64位dll，僅64位系統

④32位系統下，Any CPU模式App呼叫32位dll

⑤64位系統下，Any CPU模式App呼叫64位dll

顯而易見，Any CPU模式的dll檔案最吃香，但是我們並沒法直接看出一個dll檔案的編譯模式。

那麼該如何判斷一個dll檔案是用什麼模式編譯釋出的呢？

大家都知道百度，那麼很好，據我目前查到的結果，99%的結果都是錯的，畢竟都是轉發的，源頭錯了，其他就全錯了。

具體一點，所有關於Any CPU和32位模式的判斷都錯了。

所有轉發者只看了文章的內容，並沒有檢視該文章的討論區，甚至連文章的詳細內容都沒有看清。

只知道複製文章列出的內容：

The most interesting aspect is the PE and the 32BIT flag of the header. These combine to specify the assembly types. Here is how they would look like for:

·anycpu: PE = PE32    and  32BIT = 0

·x86:      PE = PE32    and  32BIT = 1

·64-bit:  PE = PE32+  and  32BIT = 0

然而作者自己犯了錯誤，就在這段話的上方還有一句話：

ILONLY: Managed images are allowed to contain native code. To be “anycpu” an image shall only contain IL.

這就意味著，Any CPU模式的判斷標準應該是：PE = PE32   and   32BIT = 0   and   ILONLY=1

這一點在該文章的評論區也有人提出來了，但是並沒有被任何轉發者發現。

ILSpy工具對dll的編譯模式判斷也是有錯的，請自行使用VS自帶的corflags工具檢視以上判斷資訊。

被錯誤答案狠狠坑了一把的我，連眼淚都流不下來。

明明是Any CPU模式的dll為什麼我Any CPU的App無法使用，還一直提示我模式不匹配，原來是判斷方式的錯。