组件服务 COM+ C# 不太对劲？
我正在为另一个 COM+ dll 编写一个 C# COM+ 插件。它有一个非常简单的界面，我已经成功地测试了插入。
我使用“组件服务”部分是因为旧系统这样做了，部分是因为它感觉不错。
我遇到的问题是，当我注册旧版 dll 时，属性中 dll 的路径是实际 dll，而且它也可以正常工作。
当我注册我的dll路径时，我的dll是mscoree.dll而不是我的dll，而且我是否必须将我的dll添加到GAC似乎是偶然的？我尝试过代码将其自动添加到缓存中，但它不起作用？
另外，当我在 COM+ 调用中使用 WCF 调用时，我遇到了一个问题，即配置 dll 当前位于何处，它似乎正在 C:\Windows\system32\dllhost.exe.config 中查找
设置想要让它与实际的 dll 一起查找吗？我错过了什么吗？
I am writing a C# COM+ drop in for another COM+ dll. It has a very simple interface and I have successfully tested the drop in.
I am using 'component services' partly because the old system did and partly because it feel right.
Problem I have is when I register the legacy dll the path to the dll in the properties is the ACTUAL dll, also it just works.
When I register my drop in the path to the dll is mscoree.dll not my dll, and it seems hit and miss as to whether I have to add my dll to the GAC? I have tried code to add it to a cache automatically but it doesn't work?
Also, as I am using a WCF call with my COM+ call I am running into an issue as to where the configuration dll is currently it appears to be looking for settings in C:\Windows\system32\dllhost.exe.config
What I'd like is for it to look along side the actual dll? Am I missing something?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
COM/COM+ 是一种非托管技术。它对 .NET 托管代码一无所知，因此直接在 COM 注册表中注册 .NET 程序集不可能起作用。 mscoree.dll 是 .NET 托管库，它加载托管运行时并向 COM 提供 COM 注册表所需的非托管接口。当您的程序集实现的 COM 组件类的实例被激活时，COM+ 首先加载 mscoree，然后 mscoree 必须加载您的程序集以将您的实现连接到 mscoree 向 COM+ 提供的 COM 可调用包装器。
mscoree 在哪里查找您的程序集以加载它取决于您注册它的方式。它遵循 .NET Fusion 加载程序的正常路径探测规则，这意味着它通常会在 GAC 中查找，除非您在注册期间指定了代码库（例如使用 regasm 命令行参数
/codebase） 。托管代码的配置设置由 AppDomain 限定范围，默认情况下，通过将后缀
.config添加到托管 AppDomain 的进程的可执行文件的路径来获取 AppDomain 的配置文件名。您的组件托管在 COM+ 中，因此将在作为 DllHost.exe 实例的进程中执行。因此，默认情况下，组件的 AppDomain 的配置文件将为 DllHost.exe.config。但是，如果您为 COM+ 应用程序指定应用程序根目录，这会将 AppDomain 查找其配置的位置更改为[COM+ 应用程序根目录]\[COM+ 应用程序名称].config。COM/COM+ is an unmanaged technology. It knows nothing about .NET managed code, so registering your .NET assembly directly in the COM registry could not possibly work. mscoree.dll is the .NET hosting library which loads the managed runtime and presents the unmanaged interfaces to COM which the COM registry requires. When an instance of the COM coclass that your assembly implements is activated, COM+ loads mscoree first, then mscoree has to load your assembly to hook up your implementation to the COM-callable wrapper which mscoree presents to COM+.
Where mscoree looks for your assembly in order to load it depends on how you registered it. It follows the normal path probing rules of the .NET Fusion loader, which means it will usually be looking in the GAC unless you have specified a codebase during registration (e.g. using the regasm command line argument
/codebase).Configuration settings for managed code are scoped by AppDomain, and by default the configuration file name for an AppDomain is obtained by adding the suffix
.configto the path of the executable of the process hosting the AppDomain. Your component is hosted in COM+, so will execute in process which is an instance of DllHost.exe. So by default the configuration file for your component's AppDomain is going to be DllHost.exe.config. However, if you specify an Application Root directory for the COM+ application this will change the location where the AppDomain looks for its configuration, to[COM+ Application Root Directory]\[COM+ Application Name].config.