关于如何判断dll是32位或64位的重大误区

.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位模式的判断都错了。

关于模式判断的来源：http://blogs.msdn.com/b/gauravseth/archive/2006/03/07/545104.aspx

所有转发者只看了文章的内容，并没有查看该文章的讨论区，甚至连文章的详细内容都没有看清。

只知道复制文章列出的内容：

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无法使用，还一直提示我模式不匹配，原来是判断方式的错。