c# - C++ calling managed COM object can't find dependent assemblies -
I have created and managed a managed COM library in C # on my development machine and I have successfully registered it and An .lb file is created with regasm, and successfully imported TLB in the C ++ console app used for testing.
My COM assembly is called "efcAPI.dll" and it gives reference to another assembly that has not been installed for COM or registered as "efcServerDiscovery.dll" anyway. This second DLL is some code used by my com DLL and exists in the folder similar to the FTP dll.
Everything related to loading a COM assembly is working properly I can define examples of my classes in COM and call methods by them. But when I call some methods which uses the code defined in efcServerDiscovery.dll, then I get a _com_error that reports that this file or assembly can not load 'efcServerDiscovery'.
I have verified that copy of efcServerDiscovery.dll (where only I created and registered the location with efcAPI.dll) is everywhere on my hard drive where efcAPI.dll exists. I have tried to not keep efcAPI.dll and efcServerDiscovery.dll in the same directory as a C + + app.
Any suggestions about C ++ app where it is looking for assembly or how to find where it would be great!
Yes, this is a problem with non-COM dependency having COM components. Windows does not consider the location of the DLL DLL when it searches for dependent DLL. Normal search rules are in effect, the folder contains the first EXE, Windows directory, current work directory, path environment. The location of the COM server does not play a role.
Assume that you do not want to deploy in the EXE folder, none of these is a good place to store your DLL, although many installers make desperate c: \ windows \ system32 Modify the process of storing or modifying the system path environment variable.
One thing you can do is use the SetDllDirectory () P / Assembly in your C # code before running any code in the / CLDA. Although this is not a safe thing to do, it may change the search terms of the app using your component.
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. Looking at the state, I only wish you good luck.
Comments
Post a Comment