一位客户想要使用我们来自 VB6 的 .NET DLL。它们旨在支持反向互操作，并且一切正常……除了：两个不同的目录中有两个独立的 VB6 程序。似乎有必要执行以下操作之一：
这是客户的观察，也得到了RegAsm 文档的支持：
使用 Regasm.exe 注册程序集后，您可以将其安装在全局程序集缓存中，以便可以从任何 COM 客户端激活它。如果程序集仅由单个应用程序激活，您可以将它放在该应用程序的目录中。
在这一点上我很困惑。
第一点混淆：
据我了解，COM 运行时使用 Prog ID / Class ID 定位 DLL。当我在注册表中查看 Class ID 条目时，我在 CodeBase 键中看到了 .NET DLL 的完整路径。为什么使用 Prog ID / Class ID 的 COM 程序无法使用 CodeBase 找到 .NET DLL？
困惑之二：
GAC 特定于 .NET。它如何参与解析 COM 引用？
您是正确的 COM 使用 ProgId 获取 ClassId 以获取 COM 服务器进行加载。对于 .NET COM dll，COM 服务器实际上是 MSCOREE，而不是 .NET dll（{CLSID}/localserver32 下的默认键的值）。MSCOREE，而不是 COM，然后可以使用它想要查找 .NET 程序集的任何规则。
在这一点上，我不知道 .NET 真正做了什么——这需要测试。您可以使用FUSLOGVW观察自己。但是，我可以猜测它会像加载任何其他 .NET 程序集一样加载程序集。
假设它只是使用 ClassName 值调用 Assembly.Load()，它将遵循.NET 绑定规则。首先在 GAC 中查找，如果未找到将进行探测 - 因此，如果定义了代码库，它将只查找那里，否则它将基于应用程序库进行探测（默认情况下是应用程序的目录 [但不适用于 ASP.NET ]）。
我认为这符合你在 regasm 中读到的内容。
您的问题太老了，我认为它是OBE，但是您用于将程序集放入应用程序目录、使用代码库或在 GAC中的规则与 w/o com interop 相同。每种情况都不同，我对 .NET 所做的工作还不够多，无法放弃任何深刻的见解。我喜欢 xcopy 安装，所以我会在 app 目录中使用（并使用免注册 COM），但还有其他考虑因素，例如两个 vb 应用程序是否必须使用相同版本的 COM 对象。