Deploying native Windows DLL used by .NET applications

  • Thread starter Thread starter Boris
  • Start date Start date
B

Boris

We have a native Windows DLL (let's call it native.dll) we developed a .NET
interface for (let's say managed.dll). When a .NET application now uses the
..NET interface to talk to the Windows DLL we always thought that managed.dll
must be copied to the application directory (where the .NET application
runs) and that native.dll can be anywhere as long it is in PATH or is
somehow else found by Windows.

The problem is however that the .NET application hangs on some computers
unless native.dll is copied to the application directory. The problem is
reproducable but exists only on some computers. On one computer native.dll
can be copied to the Windows directory and everything works fine. On the
other computer native.dll must be in the applicaton directory as otherwise
the .NET application hangs when it tries to access native.dll.

I used Dependency Walker (from http://www.dependencywalker.com/) to make
sure that in every scenario all DLLs can be found. Thus I wonder why on some
computer native.dll must be copied to the application directory for the .NET
application not to hang. Is there a deployment recommendation like this? Or
is this a bug in the .NET framework or CLR which doesn't locate DLLs
correctly sometimes?

Boris
 
Cor Ligthert [MVP] wrote:

Hi Cor,
Do you use the setup and deployment project tool from Visual Studio?

http://msdn2.microsoft.com/en-us/library/ms235317.aspx
Click to expand...

no, we use Inno Setup. However the problem is not related to the installer.
It can be reproduced by simply copying all files (the .NET application and
its depending DLLs) to a folder. If they are all in the folder everything
works. If I copy then native.dll to another folder like C:\Windows the .NET
application hangs. There is no error message, and Dependency Walker also
clearly shows that all DLL dependencies can be resolved. The only thing
which is different from a native Windows application is that here a managed
DLL depends on native.dll.

There is no COM involved either - no file is registered. native.dll depends
on msvcp71.dll and msvcr71.dll. It doesn't matter where these two DLLs are -
they can be in C:\Windows for example. As long as native.dll is in the
application directory everything works. Otherwise the .NET application hangs
and eats all CPU time. This is all seen on a Windows Server 2003 SP1 system.

Boris
[...]
Click to expand...
 
The problem has been solved. There were different versions of some DLLs on
the server. After cleaning up this mess everything worked again.

Boris
 
Back
Top