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

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?

[Doug Harrison [MVP]]

<Ol**********@skyscan.be> wrote:

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?

See this for the DLL search order:

LoadLibraryEx
http://msdn.microsoft.com/library/de...dlibraryex.asp

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++

> 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.

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

> 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.

[Will]

<Ol**********@skyscan.be> wrote in message
news:41**********************@news.skynet.be...

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.

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

> > 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.
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 ...
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'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.
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.
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.

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

But thanks for the tip, I really appreciate it.