1

I have a question concerning a COM C# component being created from a native C++ application.

The C# component is referencing an assembly which contains the COM interface. So project A(.dll) contains the COM interface, project B(.dll) contains the COM class that implements this interface.

This C# COM component is then registered using regasm from some folder on my system, say for example: C:\TestComponent which contains A.dll & B.dll, B being the one registered using regasm.

When my native C++ application (COM server), which is installed in another path, is trying to create an instance of the C# COM class from project B this fails complaining that A.dll can not be found.

If I copy (only) A.dll to the installation directory of my native C++ app, everything works perfectly.

Any ideas on how to tell my native C++ app that it needs to find the A.dll in a specified directory or in the directory where B.dll resides?

Kind regards, Dwight

Improve this question
2
  • I will make a big assumption here. Are you simply trying to make a native application communicate with a C# application, while hosting both "virtual" applications in the same process ? If that is the case, then I really advice you stop working with COM and simply use a more good ol' DLL-ish approach. Did you check out @Robert Giesecke's "Unmanaged Exports" template ? Have a look at: sites.google.com/site/robertgiesecke/Home/uploads/… Commented Sep 10, 2013 at 9:08
  • Do you use "regasm.exe /codebase" ? If not, try it. Commented Sep 10, 2013 at 9:12

2 Answers 2

Reset to default
2

Having dependencies in a COM server is always a problem, whether it is an unmanaged server or one written in C#. Just like Windows, the CLR will only look in a few select places for a DLL. Which are the GAC and the directory where the EXE resides. With an option to also look in subdirectories of the EXE directory by using a app.exe.config file.

Knocking off the candidates here: you'll want to avoid giving the client EXE a .config file, you don't control its location nor configuration, it is somebody else's program. Same problem with the EXE directory.

Which leaves the GAC.

Also the location that Regasm.exe prefers, just omit the /codebase option when you register after you put the assemblies in the GAC. And a very good way to solve the DLL Hell problem that's so strongly associated with COM, the GAC can store different versions of your DLLs.

Improve this answer
Sign up to request clarification or add additional context in comments.

Comments

0

As far as I understand, you only registered B.dll. That is the reason, the COM System has no knowledge, where A.dll reside. I do not know a way to tell the application where it can found a, except of changing the workingdirectory or add the path to the A.dll to the system path variable or last but not least copy the A.dll into the system32 directory (but I hate that). By the way, having a DLL proxy, like A.dll is, reside in the same directory as your application seems totally fine to me.

Ah one more thing. You can, if you now the path of the A.dll but did not want any of the above solutions, you can have a look into Loadlibrary.

Improve this answer

Comments

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.