|
dev
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
Deploying native Windows DLL used by .NET applicationsinterface 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 Boris,
Do you use the setup and deployment project tool from Visual Studio? http://msdn2.microsoft.com/en-us/library/ms235317.aspx Cor Show quote "Boris" <bo***@gtemail.net> schreef in bericht news:%23HxAoNJyGHA.4976@TK2MSFTNGP04.phx.gbl... > 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? no, we use Inno Setup. However the problem is not related to the installer. > > http://msdn2.microsoft.com/en-us/library/ms235317.aspx 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 Show quote > [...] |
|||||||||||||||||||||||