a.exe uses b.dll uses c.dll search path problem

a.exe uses b.dll uses c.dll search path problem

Post by Olaf.Baeye » Tue, 03 Aug 2004 22:13:35


We have this situation:
We have a unmanaged c++ executable located in a certain folder (a.exe)
It loads a mixed mode managed/unmanaged dll using MFC dynamically from a
completely different path (b.dll)
This last dll, uses other pure managed and mixed managed/unmanaged dll's
that uses MFC. (c.dll, d.dll,...)

What works is a.exe loading b.dll.
But once I want to use a functions in c.dll I get an exception indicating
that c.dll is not found. :-(

The off thing is that this c.dll is right there where I put b.dll, I even
moved to the location of a.dll, and put in the GAC.
What works sometimes is, if I put c.dll and d.dll into the GAC, but not
always.

I also set the current directory dynamically but to no avail. :-(

Anyone have a clue what goes wrong?
 
 
 

a.exe uses b.dll uses c.dll search path problem

Post by Doug Harri » Wed, 04 Aug 2004 00:28:41


See this for the DLL search order:

LoadLibraryEx
http://www.yqcomputer.com/

Your best bet is to put all the DLLs into the directory containing a.exe.
You could also reference them with absolute paths with the help of
GetModuleFileName, e.g. using it on the b.dll HMODULE and replacing the
filename (b.dll) part with c.dll.

--
Doug Harrison
Microsoft MVP - Visual C++

 
 
 

a.exe uses b.dll uses c.dll search path problem

Post by Olaf.Baeye » Wed, 04 Aug 2004 16:35:10

> Your best bet is to put all the DLLs into the directory containing a.exe.
Can you give more details in this?
b.dll is a managed+unmanaged dll that exposes unmanaged funtions to
unmanaged a.exe, loaded dynamically.
But c.dll is a managed dll that is used in b.dll. And c.dll is going to load
unmanaged+managed d.dll automatically.

I only have source access to b.dll.

It is hard to put this into the same location of the exe, since it is
intended as plugin for a.exe and mutiple variations might exist of that dll
name.
The goal is to install this somewhere (maybe other drive) and then let the
a.exe load it dynamically.

But thanks for your tip.
Olaf Baeyens
 
 
 

a.exe uses b.dll uses c.dll search path problem

Post by Olaf.Baeye » Wed, 04 Aug 2004 21:04:44

> Your best bet is to put all the DLLs into the directory containing a.exe.
This seems to work great.
But I still want to install this somewhere else because it is supposed to be
a plugin and must be installed in a separate folder.
 
 
 

a.exe uses b.dll uses c.dll search path problem

Post by Will » Thu, 05 Aug 2004 00:08:19


be

This is the kind of question that causes my head to hurt, trying to consider
both the managed and unmanaged rules. So take what follows as idle
speculation ...

I'm not sure about this but it may be best to split the the managed and
unmanaged code so you can load the managed and unmanaged components
separately; perhaps using Assembly::LoadFrom() or some such.

Also, if you are using XP/SP1 check the docs for SetDllDirectory() which
causes the specified directory to be bumped (almost) up to the top of the
search list, right behind the current directory that Doug suggested.

Regards,
Will
 
 
 

a.exe uses b.dll uses c.dll search path problem

Post by Olaf.Baeye » Thu, 05 Aug 2004 16:46:41

> > This seems to work great.
to
consider
Any idea might put me a step closer to solving the problem. :-)
This problem is the only problem that stays between me and writing code
fast.
The learning curve of .NET is huge (security things), but it is worth
learning it.

At this point putting the dll's in the GAC solves the problem.
Also installing it at the location of the executable that calls them also
works.

I am experimenting with this right now.
But so far, no good result, even when I use absolute paths.
Or force a current directory.

It could be nice if I could enforce some base folder for the dll.
I know that there exist something like AppDomain? But I am still trying to
understand how that works.

This is a good clue.
But it must also work on Win2000.

But thanks for the tip, I really appreciate it.