c# - 以编程方式解析 COM 引用

Question

我正在尝试列出 msbuild 项目的所有引用及其在磁盘上的位置。

到目前为止，我可以很好地获取项目引用和程序集引用，但我在处理 COM 引用时遇到了问题。这是项目文件中大多数引用的样子:

<COMReference Include="[name of assembly]">
  <Guid>{GUID-GOES-HERE}</Guid>
  <VersionMajor>1</VersionMajor>
  <VersionMinor>0</VersionMinor>
  <Lcid>0</Lcid>
  <WrapperTool>primary</WrapperTool>
  <Isolated>False</Isolated>
  <EmbedInteropTypes>True</EmbedInteropTypes>
</COMReference>

我完全不知道如何获取 COM DLL 的路径。谷歌搜索告诉我，我可以查看 HKEY_CLASSES_ROOT\CLSID\{GUID-FOUND-IN-PROJECT-FILE}\InprocServer32 并获取 key 的默认值。当我使用 regedit 查看注册表时，它似乎是正确的，但每次我通过 C# 执行此操作时，注册表项始终为空。我还查看了 Wow6432Node\CLSID，结果相同。

谷歌搜索进一步发现了 msbuild ResolveComReference task以及如何使用 Microsoft.Build 命名空间以编程方式使用 msbuild ( ResolveComReference class )，但我只发现了如何使用此命名空间来构建整个项目，而不是执行单个任务.

如何使用项目文件中的信息获取 COM DLL 的位置？

编辑

这样做的原因是为了自动化我们的构建过程。一方面，这可以让我们在安装程序中包含我们的 COM DLL(使用 WiX 的 Heat 工具，或 John Robbin 的 Paraffin 工具)。另一方面，它可以解决我们在 msbuild 中遇到的问题。我们让 msbuild 解决所有依赖项。如果 Project1 和 Project2 都引用相同的 COM DLL 而 Project1 引用 Project2，它会崩溃，因为它尝试添加 COM DLL 两次。

Answer 1

The reason for doing this is to automate our build process

这无疑是问题的一部分。 <COMReference>只有在执行构建的机器上安装了 COM 服务器时才方便。如果您想在另一台 机器上重现构建，那将成为一个问题。该计算机上未安装正确的 COM 服务器的可能性大大增加。它肯定会解释为什么您无法在注册表中找到它。

为了使构建在任何机器上都可重现，打破构建依赖性变得很重要。为此，您可以运行 Tlbimp.exe 来创建导入库。并将其 checkin 源代码管理。并添加对生成的 DLL 的常规程序集引用，这样您就只有一个简单的文件依赖项。

缺点是您会卡住依赖关系，并且在 COM 服务器发展时会遇到麻烦。样板是 {guid} 在服务器版本更改时更改，这是避免 DLL hell 所必需的。如果是这种情况，那么您将需要一个过程来确保 COM 服务器更新在执行构建的所有机器上注册。这在实践中并不是什么大问题，因为具有 COM 依赖性始终意味着您也具有部署依赖性。您还需要确保服务器在用户的计算机上可用。这总是一件大事，您几乎永远不会轻率地更改版本。