我不知道是否有使这成为可能的 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/