大家好！
在本文中，我们将解决一个非常令人沮丧的场景：确保您所有的 .net 程序集甚至本机 dll 都以相同的体系结构为目标。在撰写本文时，应用程序往往针对 x86 或 x64 架构，或两者兼而有之。然而， 混合为不同体系结构编译的 dll 或可执行文件是灾难的根源 。这种灾难，其实是：
这是一个错误的图像格式异常，它说：
“系统”类型的未处理异常。
badimageformaexception
'发生在 microsoft.visualstudio.hostingprocess.utilities.dll 中
附加信息：无法加载文件或程序集“classlibrary，version=1.0.0.0，culture=neutral，publickeytoken=null”或其依赖项之一。
试图加载格式不正确的程序。
这就是它发生的原因：
这是一件非常非常愚蠢的事情，让 x64 控制台应用程序依赖于 x86 类库（或 dll）。记住：
太好了，现在你知道了。但是无论如何你一定会遇到 badimageformatexception 问题，因为虽然很容易控制项目中程序集的位数，但你经常依赖第三方提供的 dll，并且他们自己的位数没有明确定义。不幸的是，您不能依赖右键单击 -> 属性 -> 详细信息，因为那根本不会给您带来麻烦。
不过，幸运的是，您可以使用一些工具来找出这些 dll 是针对何种架构编译的。
让我们从 .net 程序集开始。 如果有问题的 dll 是 .net 程序集，您可以 使用 corflags 实用程序 找出位数 。 corflags 是 visual studio 开发人员工具的一部分，因此您首先需要启动 visual studio 开发人员命令提示符（请参阅 此 stackoverflow 线程 或在窗口中搜索 corflags.exe ，以防您无法从开始菜单中找到它）。
找到 corflags.exe 或有 visual studio developer 命令提示符后，使用要检查的 dll 的完整路径运行 corflags.exe ，并检查输出中的 32 位 设置：
现在 corflags.exe 可以很好地找出 .net 程序集的体系结构，但不能告诉您本机 dll 的体系结构。如果您尝试将它与 sdl2.dll 一起使用，则会发生这种情况，例如：
对于非托管/本机 dll，我们可以 改用 dumpbin 。这将吐出一堆信息，因此如果您通过仅包括包含单词“机器”的行来过滤信息，您可以快速找到架构，如链接堆栈溢出答案所示：
好了——本文介绍了两种不同的方法来分别检查托管和非托管 dll 的位数或 cpu 架构，这有助于排除那些可怕的 badimageformateexceptions。事实上，这篇文章是对上面链接的两个堆栈溢出线程中信息的整合，我要感谢作者，因为我发现他们的技巧在很多场合都很有用。
本文最初于 2014 年 9 月 28 日 在 程序员牧场发布。