我不知道是否有使这成为可能的 API，或者我是否必须自己动手。这就是我想要完成的。

我有一个连接到 NT 服务以启动与另一个 COM 服务器的 session 的应用程序。

• 应用程序，客户端。
• 经纪人 NT 服务； (系统帐户上下文)。
• session COM 服务； (系统帐户上下文，将根据需要模拟用户)。

session 服务器将为连接到 NT 服务的每个应用程序实例都有一个运行实例。应用程序可以请求 session 服务器加载 COM 库 DLL，并从 session 服务器中的那些 DLL 托管对象和服务。 DLL 通过免注册激活进行注册。

从 session 服务器创建对象并将它们传回应用程序只要它们是 IDispatch 派生的就可以正常工作，这是整个系统的要求，因为脚本语言可能会使用它，这就是请求的接口(interface). C++ 应用程序还可以使用 session 服务器中托管的对象。但是 IDispatch 是一个在 C++ 中处理的过于冗长的接口(interface)。

我的问题是:

鉴于托管的 DLL 具有应用程序确实知道的双重自定义接口(interface)，并且应用程序可以通过 ITypeInfo 读取有关这些接口(interface)的类型信息；如果我可以为它提供 IDispatch 接口(interface)，是否有一个 API 在运行时会创建一个代理来模仿原始的自定义接口(interface)，该接口(interface)还带有 ITypeInfo 信息。所有代理需要的是调用 IDispatch 接口(interface)，但对 C++ 来说似乎是自定义接口(interface)。更优化的解决方案是使用相同的代理，即默认的 OLE 自动化代理，DLL 在其 list 中注册。

我无法为 DLL 注册代理/ stub ，因为多个应用程序可能具有相同的模块，但版本不同，因此使用免注册激活。

最佳答案

类型库中描述的任何 [oleautomation] 接口(interface)(和任何 [dual] 接口(interface))都可以使用类型库编码(marshal)拆收器。

在这里，您可以将查找代理 stub DLL 的麻烦换成查找类型库的麻烦。因此，您在程序集的 list 中(直接在 assembly 元素下)声明接口(interface)和类型库，如下所示:

<comInterfaceExternalProxyStub name="IFooBar"
                               iid="{IIIIIIII-IIII-IIII-IIII-IIIIIIIIIIII}"
                               proxyStubClsid32="{00020424-0000-0000-C000-000000000046}"
                               tlbid="{TTTTTTTT-TTTT-TTTT-TTTT-TTTTTTTTTTTT}" />

<!-- This also works for a type library embedded in a DLL -->
<file name="FooBar.tlb">
    <!-- If you have multiple embedded type libraries, use the resourceid attribute -->
    <typelib tlbid="{TTTTTTTT-TTTT-TTTT-TTTT-TTTTTTTTTTTT}"
             version="1.0" />
</file>

如果您的界面不是[oleautomation] 界面，并且您想要隔离代理 stub DLL，您可以使用如下内容:

<file name="FooBarPS.dll">
    <comInterfaceProxyStub name="IFooBar"
                           iid="{IIIIIIII-IIII-IIII-IIII-IIIIIIIIIIII}"
                           proxyStubClsid32="{PPPPPPPP-PPPP-PPPP-PPPP-PPPPPPPPPPPP}"
                           threadingModel="Both" />
</file>

comInterfaceProxyStub 很像 comClass，但专注于代理/ stub 并且它与接口(interface)相关联。

您可以使用一对 comInterfaceExternalProxyStub(在 assembly 元素级别)和 comClass(在 file 元素)，如果您想使用和不使用隔离的代理/ stub DLL 进行测试，通过(取消)注释代理/ stub file 部分:

<comInterfaceExternalProxyStub name="IFooBar"
                               iid="{IIIIIIII-IIII-IIII-IIII-IIIIIIIIIIII}"
                               proxyStubClsid32="{PPPPPPPP-PPPP-PPPP-PPPP-PPPPPPPPPPPP}" />

<file name="FooBarPS.dll">
    <comClass description="PSFactoryBuffer"
              clsid="{PPPPPPPP-PPPP-PPPP-PPPP-PPPPPPPPPPPP}"
              threadingModel="Both" />
</file>

我不确定，但如果您的标准代理/ stub DLL 用于多个接口(interface)，您也必须使用这种方法。

编辑:看起来这些对您来说都不是新的。您的问题是，在 session 服务中，即使您激活了动态加载库的 list ，该状态也只保留在当前线程中。因此，COM 工作线程(例如 RPC 线程)将不知道您的接口(interface)、组件类和代理/ stub 。

您在代理服务 (REGDB_E_IIDNOTREG) 中看到的错误可能源于从 session 服务返回的编码。您不会在 session 服务中遇到该错误，因为它发生在您的方法返回之后。

但是，它可能发生在代理服务中，因为它很自然:它不加载任何库，更不用说它们的 list 了。

我建议您采用的方法是使 session 服务和代理服务具有依赖于声明免注册 COM 信息的程序集的 list 。这样，它就会成为默认激活上下文的一部分，您无需对激活上下文执行任何操作。

请记住，您无法控制不属于您的线程的激活上下文，除非让默认激活上下文包含您预先需要的内容。

关于你的这部分问题:

I cannot register the proxy/stubs for the DLLs since multiple application may have the same modules, but differing in version, hence the use of registration-free activation.

我不清楚你想说什么。如果您的模块向后兼容，则无需担心。如果不是，请使用不同的 CLSID/ProgID。

我希望您并不是说您使用的是具有实际不同接口(interface)的相同 IID，因为这违反了 COM。解决这个问题的最好方法就是不这样做，期间。另一种方法是在 session 服务 和 代理服务中使用具有专用激活上下文的专用线程，正如您可能只在 session 服务中看到的那样，这是一种非常脆弱的方法。

在我看来，您可能根本不需要 COM 隔离。但是，如果您仍然需要它，则需要对服务、代理和 session 都执行此操作，并从它们的 list 中执行，而不是在运行时执行。

关于c++ - 如何在进程外客户端中获取免注册 COM 对象代理，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/31753648/