Linking external dlls

[Joerg M. Colberg]

My apologies if this is a trivial problem. I have been trying to solve
this for a few days now and I just can't get it done. Here's what I have. I
have a C++ project in VisualStudio.NET whose code relies on external C code
(GNU Scientific Library). That external code I added using
Configuration Properties->Linker->Input->Additional Dependencies
There, I specified two .lib files and the code compiles just fine. However,
when it generates the output dll's (the project is supposed to produce a
dll that is being used elseplace) the external code's dll's aren't copied
over. So I tried to the external code's dll's using "References" but that
just won't work (don't know why - the error message is non-descriptive). So
here's the question: How do I link those external libraries so that when
some other code wants to use the dll the external libraries' dll's get
copied over properly?
Should I, instead of doing the linking the way I do it, invoke the
code using dllImport? The important thing here is that the code compiles
and runs just fine the way I do it - the only problem is that the
external dlls don't get deployed properly. That's particularly bad for
the case where I use the C code inside a .NET web application: The
code won't run unless I copy the dlls by hand (hardly a solution for
a web application).


- Joerg Colberg
(e-mail address removed)

 

[William DePalo [MVP VC++]]

My apologies if this is a trivial problem.

This is a low-flame group.

I have been trying to solve this for a few days
now and I just can't get it done. Here's what I have. I
have a C++ project in VisualStudio.NET whose code
relies on external C code (GNU Scientific Library). That
external code I added using Configuration
Properties->Linker->Input->Additional Dependencies
There, I specified two .lib files and the code compiles
just fine.

So far, so good.

However, when it generates the output dll's (the
project is supposed to produce a dll that is being used
elseplace) the external code's dll's aren't copied over.

Right. They won't be. At runtime Windows searches for DLLs in an order that
is described in the Remarks section on this page:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/loadlibrary.asp

If you want the DLLs to be implicitly loaded then you have to put the
dependent DLLs where the loader will look for them.

Regards,
Will

 

[Joerg M. Colberg]

Hi Will,

Thanks for the answer! I have a follow-up:

Right. They won't be. At runtime Windows searches for DLLs in an order
that is described in the Remarks section on this page:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/loadlibrary.asp

If you want the DLLs to be implicitly loaded then you have to put the
dependent DLLs where the loader will look for them.

Where would that be? In particular, when I incorporate the
C code into a web application I need to make sure the dlls get
accessed. For example, if I put the dlls into a directory that's
in the PATH (or even into the system directory [I'm somewhat
reluctant to do that...]) would the web server look there?

Best,
Joerg

 

[William DePalo [MVP VC++]]

Thanks for the answer! I have a follow-up:

You are welcome.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/loadlibrary.asp

Where would that be?

The loader's search order is spelled out in the remarks section of the help
entry on the LoadLibrary() function above.

In particular, when I incorporate the
C code into a web application I need to make sure the dlls get
accessed. For example, if I put the dlls into a directory that's
in the PATH (or even into the system directory [I'm somewhat
reluctant to do that...]) would the web server look there?

If we are talking about implicit linking, as would be the case when your DLL
is linked against the third party's DLL, then at the time your DLL is loaded
Windows' loader will try to resolve the imported references in your DLL
using the search order above.

If your DLL is implicitly linked against the web server, then the loader
will search the directory containing the web server and the current
directory in force at the launch of the web server.

If your DLL is explicitly loaded then the current directory is the current
directory in force when the web server calls LoadLibrary() to load your DLL.

Your reluctance to pollute the Windows directory or Windows system directory
is a point of view appreciated by system administrators the world over.
There are those people who do that, though, because an application can
continue to work even if the user copies it manually to another directory as
the system directory doesn't move.

That approach devolves into something called "DLL hell" when the third party
DLL is a common one which is installed by two applications which use
different versions of it. That can and often does break something.

So, these days, people tend not to worry about the waste in disk space but
tend to put the DLLs used by an application, even if shared, in one of the
application's directories.

Does the web server not spell out a "best practices" policy?

Regards,
Will

 

[Joerg M. Colberg]

Hi Will,

Your reluctance to pollute the Windows directory or Windows system
directory is a point of view appreciated by system administrators the
world over. There are those people who do that, though, because an
application can continue to work even if the user copies it manually to
another directory as the system directory doesn't move.

That approach devolves into something called "DLL hell" when the third
party DLL is a common one which is installed by two applications which use
different versions of it. That can and often does break something.

So, these days, people tend not to worry about the waste in disk space but
tend to put the DLLs used by an application, even if shared, in one of the
application's directories.

I'm in a bit of a dilemma here because I don't really know the webserver
to well, and all my efforts to put those dll's into places where I thought
the webserver would look didn't work. So I ended up putting the dll's into
the Windows system directory *boooo hisss*. Given the fact that I am also
the system admin I don't expect any trouble from that guy. ;-) But
seriously, I think putting the dll's there is... well... let's call it
OK: I will never ever change the dll's myself and I don't expect them to
change (it's a bunch of libraries used for all kinds of scientific
programming). On top of that, I need to focus on getting the application
running etc. so I can't afford to spend too much time on this. Hardly
ideal, but what can you do?
In any case, your comments helped me solve the problem. If I ever
manage to find out where else I can put the dll's I'll put them there
and clean up the system directory. But you know, it's a Windows system
and Windows isn't exactly know for pretty solutions. ;-)

Anyway, thanks a bunch for the help!

Best,
Joerg

 

[William DePalo [MVP VC++]]

I'm in a bit of a dilemma here because I don't really know the webserver
to well, and all my efforts to put those dll's into places where I thought
the webserver would look didn't work. So I ended up putting the dll's into
the Windows system directory *boooo hisss*. ...
On top of that, I need to focus on getting the application
running etc. so I can't afford to spend too much time on this. Hardly
ideal, but what can you do?

That's the usual quandary.

But you know, it's a Windows system and
Windows isn't exactly know for pretty solutions. ;-)

Joerg, Joerg, Joerg.

You know if you said you were using IIS and its ISAPI extensions I could
have pointed you to an ISAPI group where I'm sure you could get lots of
information on best practices for deployment. This is Windows, after all,
and there is more written and known about Windows than any antique operating
system whose name ends in X. <BSEG> There are even books that document the
undocumented.

And look at the loader's search algorithm. There are plenty of places to put
things besides the system directory. You can't blame Windows. It offers you
choices, some better than others. In the end, we are all responsible for our
choices.

Anyway, thanks a bunch for the help!

You are welcome.

Regards,
Will