强制 .NET 互操作使用本地 COM DLL
是否可以强制互操作程序集引用其关联的 COM DLL 的本地副本？
场景如下：
我有一个引用互操作程序集 (Interop.OTAClient.dll) 的 .NET 应用程序，该程序集是 COM DLL 的互操作程序（OTAClient.dll，它是 HP Quality Center 的自动化 API）。 我对 COM 不太了解，但据我了解，互操作程序集通过注册表中的 GUID 引用查找 COM 类，而不是指向特定文件。
我遇到的问题是，注册表项指向的 OTAClient.dll 副本会被不同版本覆盖，具体取决于我刚刚在浏览器中登录的 QC 版本，并且这些 DLL 的不同版本与彼此。 .NET 应用程序只会连接到特定版本的 QC，因此我不能让 COM DLL 以这种方式变化。
任何建议将不胜感激，因为这种行为确实令人恼火。 我见过关于 COM 互操作问题的其他问题，但它们似乎都是关于强制使用互操作 DLL 的本地版本而不是 GAC 中的版本，而不是涉及实际 COM DLL 的这一特定场景。
Is it possible to force an interop assembly to reference a local copy of its associated COM DLL?
Here's the scenario:
I have a .NET app that references an interop assembly (Interop.OTAClient.dll), which is the interop for a COM DLL (OTAClient.dll, which is the automation API for HP Quality Center). I'm not very knowledgable on COM, but as I understand it the interop assembly looks up the COM classes via GUID references in the registry, rather than pointing to a specific file.
The issue I have is that the copy of OTAClient.dll that the registry keys point to gets overwritten by different versions depending on which version of QC I've just logged into in a browser, and the different versions of these DLLs are not compatible with each other. The .NET app will only be connecting to a specific version of QC, so I cannot have the COM DLL varying in this way.
Any suggestions would be greatly appreciated, as this behaviour is really irritating. I've seen other questions on COM interop issues, but they all seem to be about forcing a local version of the interop DLL to be used instead of one in the GAC, rather than this particular scenario involving the actual COM DLL.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
帕维尔为我指明了正确的方向，所以我将把他的答案标记为答案。 为了其他人的利益，我做了以下事情：
这样，您就可以登录和注销其版本与您的应用程序使用的版本不同的 QC 实例，而不会破坏它。 就我而言，我有一个 v9 的本地 QC 实例，用于特定于项目的自动化（出于各种原因，它经过大量定制以满足我们的需求，有大量的空间用于屏幕截图存储等），并且我的应用程序连接到该实例。 但是，对于手动测试，我还需要在 IE 中使用登录到位于其他地方的 v9.2 实例。 如果我之前登录过 v9.2 实例，那么我必须在 IE 中打开 v9 实例并让它重新下载控件，然后才能再次运行我的应用程序......但现在我不需要。 :)
Pavel pointed me in the right direction, so I will be marking his as the answer. For the benefit of everyone else, here's what I did:
This way, you can be logging in and out of QC instances whose versions differ from the one used by your app without breaking it. In my case, I have a local QC instance that is v9 and used for project-specific automation (for various reasons, it's heavily customised to meet our needs, has lots of space for screenshot storage etc), and to which my application connects. However, for manual testing I also need to login using in IE to a v9.2 instance located elsewhere. If I had previously logged into the v9.2 instance, I would then have to open the v9 instance in IE and let it redownload the controls before running my app again... and now I don't. :)
您需要免注册COM。
You want Registration-free COM.
一个小示例显示了将isolated属性设置为true后Web.config如何变化，这将帮助其他人理解当我们将isolated属性设置为true时实际发生的情况。 VS 实际上在您的代码中输入了几行，以便它将使用特定 CLSID 的 com Dll。
实际上，我在同一台服务器上确实有两个 .Net 应用程序，其中一个应用程序使用 Quality Center 10.0 Dll，其他应用程序升级到 Quality Center ALM 11.0。 所以在同一台服务器上我们不能注册同名的DLL。
A small example showing how Web.config changes after we set Isolated property to true, would help others in understanding what is actually happening at back when we set Isolated property to true. VS actually enters few lines in your code, so that it will use com Dll of specific CLSID.
Actually I do have two .Net applications on the same server, where one application uses Quality center 10.0 Dll and Other is upgraded to quality center ALM 11.0. So on the same server we can not register a DLL with same name.