【发布时间】：2011-04-04 21:04:28
【问题描述】：
正如标题所说，如果我更改 vb.net 程序集的目标 cpu，会破坏二进制兼容性吗？
【问题讨论】：
-
您能否更具体地说明您要避免的问题是什么？
-
我会这么认为 - 但我不确定（因此有此评论）。
【发布时间】：2011-04-04 21:04:28
【问题描述】：
“二进制兼容性”是一个 VB6 术语，它与生成 COM dll 相关，该 COM dll 对接口和类使用相同的 Guid，因此您可以更新现有的 dll，而不必担心您的更新会破坏现有的程序。 .NET 代码的规则完全不同，抖动有很大帮助。
DLL 项目的平台目标设置也不是很相关。只有 EXE 项目的设置很重要，它决定了进程的位数。如果它依赖于旧的 32 位代码，您可以考虑将您的 DLL 强制为 x86。这将使程序在 BadImageFormatException 上更快地崩溃，而不是得到一个模糊的 COM 异常。
【讨论】：
-
我们实际上有另一种方式，一个使用这个程序集的 32 位可执行文件。现在，在 x86 环境中这不是问题，但在 x64 环境中这确实会成为问题（并且您提到的 BadImageFormatException 随之而来）我想弄清楚的是更改平台目标是否会导致更新dll 以不破坏我们现有的程序（“二进制可比性”可能仍然相关，因为调用应用程序是 VB6？）
-
DLL 程序集应始终在平台目标设置为 AnyCPU 的情况下进行编译。因此，无论哪种方式，它们都能正常工作。如果您知道 EXE 作为 32 位进程运行这一事实，我不清楚如何获得该异常。他们拥有自己的注册表视图，他们将无法找到或加载 64 位 COM 服务器。不同的例外。对您的假设进行三次检查，即 EXE 正在 32 位模式下执行。例如，您会在 TaskMgr.exe 的“进程”选项卡中看到 *32。
-
是的，调用应用程序确实在 32 位模式下运行（它在进程列表中有 *32）。
-
如果您根本不知道是什么 DLL 导致了此异常，请使用 SysInternals 的 ProcMon 实用程序。您将看到 EXE 搜索并打开 .dll 文件。异常前的最后一个是问题之一。