2

我正在尝试列出 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并获取密钥的默认值。当我使用 regedit 查看注册表时，似乎是正确的，但每次我通过 C# 执行此操作时，注册表项始终为空。我也查看Wow6432Node\CLSID了相同的结果。

谷歌搜索进一步发现了 msbuildResolveComReference任务以及我如何使用Microsoft.Build命名空间以编程方式使用 msbuild （ResolveComReference 类），但我只找到了如何使用这个命名空间来构建整个项目，而不是执行单个任务。

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

编辑

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

4

1 回答 1

6

这样做的原因是为了自动化我们的构建过程

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

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

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

于 2013-06-23T17:22:27.483 回答