6 replies to this topic

[peterc]

I'm trying to understand more about dll search order and "DLL Hell". From what I have read, one way to avoid DLL Hell is to put all the required dlls in the application folder. However, I have read that Windows 2003 and XP SP1 have changed dll search order. I wonder how others deal with this change.

Thank you for any help,

Peter

[Glytzhkof]

How is the dll search order changed? I have never heard about this.

[Stefan Krueger]

If you put a applicationname.local file in the application folder, Windows will try to load any DLL from that directory first, instead of the Windows or System folder.

[Lanman]

I need to know if this is still working in XP SP2. Am i right in my presumption that i only have to create an empty text file and rename it to cgitrans.local for example?

Thanks
Lanman

Edited by Lanman, 27 May 2005 - 10:12.

[Stefan Krueger]

Yes this should work. The file should be named like
yourapp.exe.local

[mandy]

Just to clarify - this feature is only used for registered COM components.

It causes the "InprocServer32" or "LocalServer32" paths in the registry to be ignored.

You still have to include (and register) a "shared" copy of the file in the usual "shared" location (usually "System32").

It is preferable to use the "IsolatedComponents" table to create these ".local" files automatically when using MSI technology.

This technique has several known limitations.

The standard search order should cause dlls in the local application folder to be loaded first anyway.

Use the Sysinternals ProcXPNT tool to see where the Dll was loaded from.

[Lanman]

Thanks this worked wonderfull.