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

发布时间：2020-12-14 04:32:08 所属栏目：Windows 来源：网络整理

导读：我有一个托管(asp.net,实际上)项目引用一个COM DLL.现在,.csproj中的引用如下所示： COMReference Include="thenameinquestion" Guid{someguidhere}/Guid VersionMajor1/VersionMajor VersionMinor0/VersionMinor Lcid0/Lcid WrapperTooltlbimp/WrapperTool/

我有一个托管(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还不够好,不能提出一个实际的用法示例.有可能做我想要的吗？我在正确的轨道上吗？

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

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

一旦你这样做,你不再需要在构建.NET解决方案时在机器上注册COM DLL,只需要你的互操作程序集.

互操作程序集可以一直保持不变,直到(a)COM DLL破坏二进制兼容性,或(b).NET代码实际使用的COM接口更改.

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

另外,如果您可以假设COM DLL已经安装在目标计算机上,那么您不需要将COM DLL包含在安装程序中.

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!