C ++调用受管COM对象无法找到依赖程序集 [英] C++ calling managed COM object can't find dependent assemblies

查看:167
本文介绍了C ++调用受管COM对象无法找到依赖程序集的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我在我的开发机器上的C#中创建并注册了托管COM库。我成功注册了它,并创建了一个。reglb的.tlb文件,并成功将tlb导入到用于测试的c ++控制台应用程序中。

I've created and registered a managed COM library in C# on my development machine. I've successfully registered it and created a .tlb file with regasm, and successfully imported the tlb into a c++ console app used for testing.

我的COM程序集称为 efcAPI.dll,它引用了另一个尚未设置为COM或以efcServerDiscovery.dll注册的程序集。这第二个dll包含我的COM dll使用的一些代码,并存在于同一文件夹中的efcAPI.dll。

My COM assembly is called "efcAPI.dll" and it references another assembly that has not been set up for COM or registered in anyway called "efcServerDiscovery.dll". This second dll contains some code used by my COM dll and exists in the same folder as efcAPI.dll.

关于加载COM组件的一切工作正常。我可以创建在COM中定义的我的类的实例,并从它们调用方法。但是当我调用某些使用efcServerDiscovery.dll中定义的代码的方法时,我得到一个_com_error,它报告无法加载文件或程序集efcServerDiscovery。

Everything concerning loading the COM assembly works fine. I can create instances of my classes defined in the COM and call methods from them. However when I call certain methods that use the code defined in efcServerDiscovery.dll I get a _com_error which reports that it could not load file or assembly 'efcServerDiscovery'.

验证,我的硬盘上的efcAPI.dll存在的每个地方有一个efcServerDiscovery.dll的副本(这只是我创建的位置,并注册efcAPI.dll)。我也试图把efcAPI.dll和efcServerDiscovery.dll放在同一个目录下的c ++应用程序没有成功。

I've verified that everywhere on my hard drive where efcAPI.dll exists there's a copy of efcServerDiscovery.dll (which is just the location I built and registered efcAPI.dll from). I've also attempted to place efcAPI.dll and efcServerDiscovery.dll in the same directory as the c++ app with no success.

有关c ++应用程序寻找组件或如何发现它在哪里看起来会很棒!

Any suggestions as to where the c++ app is looking for the assembly or how to discover where it's looking would be great!

推荐答案

是的,这是COM组件的问题非COM依赖关系。 Windows在搜索依赖DLL时不考虑COM DLL的位置。正常的搜索规则实际上是包含EXE的文件夹,Windows目录,当前工作目录,PATH环境。 COM服务器的位置不起作用。

Yes, this is a problem with COM components having non-COM dependencies. Windows doesn't consider the location of the COM DLL when it searches for dependent DLLs. The normal search rules are in effect, the folder that contains the EXE first, Windows directories, current working directory, PATH environment. The location of the COM server does not play a role.

假设您不想部署到EXE文件夹,这些都不是很好的地方存储您的DLL ,虽然许多安装程序做了绝望的移动存储在c:\windows \system32或修改系统PATH环境变量。

Assuming you don't want to deploy to the EXE folder, none of these are good places to store your DLL, although plenty of installers made the desperation move of storing it in c:\windows\system32 or modify the system PATH environment variable.

你可以做的一件事是在运行DLL中的任何代码之前,在C#代码中调用P / Invocation SetDllDirectory()。使用Assembly.GetExecutingAssembly()。位置会做。然而,这不是一个安全的事情,它可能会改变使用您的组件的应用程序的搜索规则。

One thing you could do is P/Invoke SetDllDirectory() in your C# code before running any code in the DLL. Using Assembly.GetExecutingAssembly().Location will do it. That is however not a safe thing to do though, it might alter the search rules for the app that uses your component.

唯一真正的解决方法是安装DLL Windows并行缓存(WinSxS),并在您的C#可执行文件中包含一个清单。鉴于文档的状态,我只能祝你好运。

The only real fix is to install the DLL in the Windows side-by-side cache (WinSxS) and to include a manifest in your C# executable. Given the state of the documentation, I can only wish you the best of luck.

这篇关于C ++调用受管COM对象无法找到依赖程序集的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆