如何在进程外客户端中获取免注册COM对象代理

Question

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

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

• 申请，客户。
• 经纪人NT服务; （系统帐户上下文）。
• 会话COM服务; （系统帐户上下文，将根据需要模拟用户）。

会话服务器将为连接到NT服务的每个应用程序实例提供一个运行实例。 应用程序可以请求会话服务器从会话服务器中的这些DLL加载COM库DLL和宿主对象和服务。 DLL通过无注册激活注册。

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

我的问题是：

假定托管的DLL具有应用程序确实知道的双自定义接口，并且应用程序可以通过ITypeInfo读取有关这些接口的类型信息; 是否有一个API在运行时将创建一个代理来模仿原始的自定义接口，如果我可以提供IDispatch接口，它还带有ITypeInfo信息。 所有代理需求都是调用IDispatch接口，但在C ++中显示为自定义接口。 更优化的解决方案是使用相同的代理，即默认的OLE自动化代理，DLL在其清单中注册。

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

Answer 1

类型库中描述的任何[oleautomation]接口（以及任何[dual]接口）都可以使用类型库封送器。

在这里，您将查找代理存根DLL的麻烦转换为查找类型库的麻烦。 因此，您在程序集的清单（直接在assembly元素下）声明接口和类型库，如下所示：

<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]接口，并且您想要隔离代理存根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 ，但专注于代理/存根，并且它与接口相关联。

您可以使用一对comInterfaceExternalProxyStub （在assembly元素级别下）和comClass （在file元素下）实现相同的效果，以防您想要使用和不使用隔离的代理/存根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>

我不确定，但如果您的标准代理/存根DLL用于多个接口，您也必须使用此方法。

---

编辑：似乎这对你来说都不是新鲜事。 您的问题是在会话服务中，即使您激活动态加载的库的清单，该状态仍然只在当前线程中。 因此，COM工作线程（例如RPC线程）将不知道您的接口，coclasses和代理/存根。

您在代理服务（ REGDB_E_IIDNOTREG ）中看到的错误可能源自会话服务的封送。 您没有在会话服务中收到该错误，因为它在您的方法返回后发生。

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

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

请记住，除了让默认激活上下文包含您需要的内容之外，您无法控制您不拥有的线程的激活上下文。

关于你的这部分问题：

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

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

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

在我看来，你根本不需要COM隔离。 但是，如果您仍然需要它，则需要为服务，代理和会话执行此操作，并从清单中执行，而不是在运行时执行。

Answer 2

一种选择是放弃硬类型的双接口，并通过硬编码，编译时生成的智能指针包装器使用IDispatch -only dispinterfaces。 您可以使用VC ++ #import和raw_dispinterfaces和/或no_dual_interfaces选项来生成这些选项。

COM封送程序不需要类型库来编组IDispatch::Invoke调用。 但是，您需要针对要并行运行的类型库/ DLL的版本进行编译。 或者至少确保所有版本的COM DLL中的DISPID和方法签名保持不变。 AFAIR，生成的智能指针不使用IDispatch::GetIdsOfNames ，因此IDispatch::GetIdsOfNames是硬编码的。

与直接双接口调用相比， IDispatch::Invoke性能可能是次可选的，但我认为这并不重要，给出了您所描述的进程间调用方案。 编组的进程外COM调用比进程内IDispatch::Invoke调用昂贵得多。