是否可以通过路径而不是GUID在托管项目中引用COM DLL？

Question

我有一个托管(实际上是asp.net)项目,它引用了一个COM DLL.现在,.csproj中的引用如下所示:

<COMReference Include="thenameinquestion">
  <Guid>{someguidhere}</Guid>
  <VersionMajor>1</VersionMajor>
  <VersionMinor>0</VersionMinor>
  <Lcid>0</Lcid>
  <WrapperTool>tlbimp</WrapperTool>
</COMReference>

这是有效的,但它有一个令人遗憾的结果,DLL需要在构建机器上注册,这意味着(除其他外)在同一构建机器上构建使用不同版本的DLL的项目的多个版本是不方便的.

MSDN显示ResolveComReference任务看起来它做的正确,但我的google-search-fu还不够好,无法提供其使用的实际示例.有可能做我想要的吗？我是在正确的轨道上吗？

Answer 1

引用COM DLL时,Visual Studio会自动为其生成互操作程序集.我发现手动控制这个过程是解耦COM和.NET构建的好方法.

1. 使用创建自己的COM DLL的互操作程序集tlbimp.exe.有关命令行参数,请参阅MSDN.
2. 在.NET项目中引用interop程序集而不是 COM DLL.

执行此操作后,您不再需要在构建.NET解决方案时在计算机上注册COM DLL,只需要您的互操作程序集.

互操作组件可以坐在永远不变,直到为(a)的COM DLL中断二进制兼容性,或(b)的COM接口做出改变,该.NET代码实际上使用这样的时间的文件夹.

如果您有不同版本的COM DLL,它们都是二进制兼容的,那么请根据包含.NET代码所需接口的最早版本编译互操作程序集.然后,您将不必更新不同版本的互操作程序集.

此外,如果您可以假定COM DLL已经安装在目标计算机上,则无需在安装程序中包含COM DLL.

Answer 2

正如John Fisher已经指出的那样，您正在寻找免注册 COM Interop。已经有很多与此相关的问题，请查找“手头标签” regfreecom以及密切相关的标签sxs。

然而，您很容易发现这可能是一个棘手的领域，特别是：

• Windows XP 上似乎存在影响此问题的已确认错误，请参阅此处了解详细信息。不过，已经有一个修补程序可用，只要您仅针对受控环境（例如您的构建机器），这可能就足够了。
• 由于您的目标是 ASP.NET，因此您应该意识到，与桌面应用程序等相比，这意味着您无法控制托管进程，这可能会因部署平台而异。这意味着提供所需的应用程序清单来控制主机内 COM 组件的运行时绑定和激活并不容易（请参阅下一点以了解潜在的替代方案）。
• ASP.NET 2.0 似乎通过放弃非托管组件的并行功能使事情变得更加复杂。我还没有找到这方面的官方来源，但Isolating ASP .Net 2.0 Applications的作者似乎知道这一点；他至少提供了一种解决方法，虽然看起来很复杂而且可能很脆弱。

总结一下，我想强调“免注册 COM 互操作”非常有帮助，可以大大简化许多场景。但对于您的特定场景和环境（托管 ASP.NET）来说，它可能不会让事情变得更容易，甚至根本不可能。

祝你好运，请让我们知道你是否成功！