64 位 COM dll 和 C#/.Net 应用程序之间的免注册互操作 [英] Registration-free Interop between a 64-bit COM dll and a C#/.Net application

问题描述

我正在尝试在 64 位 COM dll 和 C# 应用程序之间实现免注册的 COM 互操作.

I am trying to get registration-free COM interop between a 64-bit COM dll and a C# app to work.

在上一个问题的答案中我的，我得到了帮助，使我能够在 C# 的 64 位 COM dll 上成功调用 HelloWorld 方法.

In the answers to a previous question of mine, I got help that allowed me to successfully call a HelloWorld method on the 64-bit COM dll for C#.

然而，这只能通过使用 regsrv32.exe 全局注册 COM dll 来实现.

However, this was only possible by registering the COM dll globally using regsrv32.exe.

基于这个答案对一个相关问题，我认为我需要在参考上设置隔离标志COM dll 为真.但是，这会导致以下构建错误:

Based on this answer to a related question, I think that I need to set the Isolated flag on the reference of the COM dll to true. However, this leads to the following build error:

Problem isolating COM reference 'ComLibInteropLib': 
    No registered classes were detected for this component.

MSDN 社交问题的答案 似乎表明有如果可以编译 32 位版本的 dll，则可以解决此问题.

The answer to a question on MSDN social seems to indicate that there is a solution for this problem if one can compile a 32-bit version of the dll.

但是，我的 COM 互操作库需要链接到一个普通"的 C++ dll，我没有源代码，并且只能作为 x64 使用.

However, my COM interop library needs to link to a 'normal' C++ dll, for which I do not have the source and that is only available as x64.

所以我的问题是:如何在 64 位 COM dll 和 C# 应用程序之间启用隔离标志(或以其他方式并排工作)?

So my question is: How can I enable the Isolated flag (or otherwise get side-by-side to work) between a 64-bit COM dll and a C# application?

我很高兴在我的机器或其他开发人员的机器上使用 regsrv32.exe，但我们无法在最终应用程序必须运行的生产机器上注册任何 COM dll.

I am happy to use regsrv32.exe on my machine or other developer's machine, but we cannot register any COM dlls on production machines, where the final application must run.

推荐答案

这是您遇到的原始问题的副作用，COM 服务器未正确注册.当您将 Isolated 选项设置为 true 时，构建系统会自动为您生成所需的清单条目.但是清单的内容需要来自某处，它使用注册表项.由于它们不在那里，因此无法生成清单.

This is a side-effect of the original problem you had, the COM server wasn't getting registered properly. When you Isolated option to true, the build system auto-generates the required manifest entries for you. But the content of the manifest needs to come from somewhere, it uses the registry keys. Since they are not there, it can't generate the manifest.

您可以自己编写清单，但这需要对清单的外观有足够的了解.由于犯错的几率非常高，咒语非常晦涩.所以避免这种情况，您只需要注册 COM 服务器即可获得成功.就在您的构建机器上，它不必在客户端机器上注册，因为它将使用清单.

You can write the manifest yourself but that requires enough insight in what the manifest should look like. With very high odds of making mistakes, the incantations are quite obscure. So avoid that, you just need to get the COM server registered to get ahead. Just on your build machine, it doesn't have to be registered on the client's machine since it will use the manifest.

您提到了 64 位 COM 服务器，这是另一种可能的故障模式.构建系统仍然是 32 位的，因此您很有可能查看错误的键.HKLMSoftwareWow6432Node 而不是 HKLMSoftware.通过构建两种风格的 COM 服务器来解决这个问题.自己使用Regsvr32.exe时要注意同样的问题，有两个.c:windowssyswow64 中的那个应该用于注册服务器的 32 位版本，c:windowssystem32 中的一个用于 64 位版本.

You mentioned a 64-bit COM server, that's another possible failure mode. The build system is still 32-bit so you'll have high odds that it looks at the wrong keys. HKLMSoftwareWow6432Node instead of HKLMSoftware. Battle that problem by building both flavors of the COM server. Beware of having the same kind of problem when you use Regsvr32.exe yourself, there are two of them. The one in c:windowssyswow64 should be used to register the 32-bit version of the server, the one in c:windowssystem32 for the 64-bit version.

这篇关于64 位 COM dll 和 C#/.Net 应用程序之间的免注册互操作的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！