.net - COM 注册 : does location matter?

Question

我在一个解决方案中有两个项目 - 例如，ProjectA 和 ProjectB。这两个项目都注册了 COM 互操作，并且 ProjectA 引用 ProjectB - 当 ProjectA 构建时，它复制 ProjectB.dll进入其输出文件夹。

现在，COM 客户端需要访问 ProjectB.tlb。我尝试使用构建后事件将类型库从 ProjectB 的输出文件夹xcopy 到 ProjectA 的；乍一看，这是有效的——COM 客户端可以“看到”.tlb 中的类型。

问题在于，每当 COM 客户端尝试调用 .tlb 中的方法时，就会发生自动化错误。

我的直觉是需要在使用它的位置创建/注册 .tlb，所以我取消选中 ProjectB 中的“register for COM interop”框，删除 xcopy 从生成后事件中，并在 ProjectA 的生成后事件中添加一个 regasm.exe/tlb 调用，从而创建并在 ProjectA 的输出文件夹中注册 ProjectB.tlb... 然后我清理并重建了解决方案。

同样的事情:COM 客户端看到了类型，但是当它试图实际使用公开的 API 时会抛出一个自动化错误。

这两个项目原本是同一个项目。我们决定拆分它们，这样当我们发布 ProjectA 的更新时，我们可以这样做而不会导致引用 ProjectB 中代码的 COM 客户端出现兼容性问题。这个想法似乎很好，但是……这可能吗？如果是，怎么办？

或者将 ProjectB 折叠回 ProjectA 我唯一的希望是让 COM 客户端与 ProjectB 公开的 COM API 一起工作？

Answer 1

TLB 位置无关紧要；它只是编译器利益的元数据。它不在运行时使用。但是，.NET 必须能够在运行时定位程序集 DLL，而这可能很微妙。

.NET 将尝试使用通常的 Fusion 探测规则来定位 DLL，这些探测规则基于客户端进程 EXE 的位置，而不是 DLL 或 TLB 的位置事情。这基本上给了你三个选择:

• 您可以将 两者 ProjectA.DLL 和 ProjectB.DLL 复制到与客户端 EXE 相同的文件夹中。

我不这样做，因为我发现它非常...不像 COM。这让人们感到惊讶。此外，客户端通常位于不方便的位置(例如 IIS 主机进程)。

这给您留下了另外两个选择:

• 您可以将这两个 DLL 都放入 GAC 中。 (请注意，这是独立于运行 regasm.com 以注册 COM 互操作程序集的步骤。)

• 在COM中注册程序集时可以添加regasm.exe的/Codebase参数，指定.NET要记住DLL注册到哪里是，并在运行时在同一位置查找它。

请记住，无论如何，您都必须对这两个程序集运行 regasm.exe，以便在将要运行它们的计算机上为 COM 互操作注册它们。

删除“为 COM 互操作注册”选项仅意味着对 COM 互操作可见的类只有那些明确具有 [ComVisible] 属性的类。选中该选项后，每个与 COM 兼容的类都将可见。