DotLocal (.local) Dll Redirection

If you are developing software on Microsoft Windows platform, you probably have heard of the term “Dll Hell”.


“Dll Hell” happens when two applications install two incompatible versions of a shared dll. Since there is no versioning control for dll in Windows, the second copy may overwrite the first copy. As a result, the first application will not function any more.


Since LoadLibrary will search the application directory first, among other things, a workaround for the “Dll Hell” is to carry the “shared” dll with the application, which effectively makes the “shared” dll private.


But there is another kind of “Dll Hell” which can not be easily worked around. And this is COM.


If two incompatible versions of a COM server is installed and registered, even the two COM servers may reside physically in different location, there is only one place to register the COM server. Hence only the latest registered COM server will be activated. This is essentially another manifest of the “Dll Hell” problem.


To workaround this problem, a “Dll redirection” mechanism is introduced in Windows 2000.


For an application foo.exe, if there is a file foo.exe.local exists, Windows will first look at foo.exe’s application directory, before start the regular dll search. To mitigate the COM problem, the redirection applies both to full path dll loading, as well as partial name loading.


In Windows XP and Windows Server 2003, the behavior of DotLocal(.local) is altered a little bit. If foo.exe.local is a file, Windows will keep the same behavior as Windows 2000. But if foo.exe.local is a directory, Windows will search foo.exe.local directory for the dll, instead of the application directory.


In Windows XP and above, Windows (via fusion team) introduced a new side by side programming model for application isolation. This model essentially is the same model introduced in .Net framework (with no surprise, as both models are designed by the same team, with small variances based on the need of the specific product). In Windows the metadata is stored in a XML file (typically called a manifest file), as opposite to the assembly binary in .Net framework.


Since the side by side isolation model is a logic evolution of the DotLocal(.local) dll redirect, in Windows XP  and Windows Server 2003, when there is an application manifest (foo.exe.manifest, or a Win32 resource of ID RT_MANIFEST, Type 1), the DotLocal dll redirection is disabled.


It turns out the DotLocal(.local) dll redirection has a huge value in private testing. When developing a new version of the COM server, you don’t really want to mess up with the one in system. If you can redirect the dll to a private version for a set of specified applications, and let other applications use the system one, it will be the best of all the world. And DotLocal(.local) provides exactly that, with the exception that if the application has a manifest, DotLocal(.local) dll redirect is disabled.


Realizing the value of DotLocal(.local) dll redirection in private testing, a change is made in Windows Vista, that when the registry HKLM\Software\Microsoft\WindowsNT\CurrentVersion\Image File Execution Options!DevOverrideEnable:REG_DWORD is set to 1, DotLocal(.local) dll redirection will be enabled, even if the application has a manifest.


This change is in Windows Vista Beta1 and beyond. It will require a machine reboot to make the change take effect.

Comments (15)
  1. Another resource is Microsoft’s "DLL Help Database" which helps identify DLL version conflicts.

  2. Thomas says:

    Nice new feature in Vista! This will be useful when testing.

    BTW, side-by-side installation is a nice feature, but there is a major limitation when installing such DLLs that does not exist in the managed GAC: you cannot install things side-by-side if you run a "per user" installation.


  3. Thomas,

    Thanks for the links.

    You can still install SideBySide assemblies local. It is just that the VC runtime redist does not support that. You just need to copy the VC runtime manifest and its payload locally.

  4. Norman Diamond says:

    I’ve also had problems registering COM DLLs that were carried around with the application. Depending on the pathname of the folder containing these files, Windows XP SP2 can’t even find the DLL any more.

    I didn’t have enough time to track it down completely, but it seems that part of the problem was due to the pathname being a perfectly ordinary descriptive name for this country and the language version of Windows XP SP2 that it was installed on. I.e. the pathname did not entirely consist of Italian characters.

    I didn’t have time to figure out how to do a side-by-side installation in hopes that it might work around the problem.

  5. Carlos says:

    This is a bit off topic, but maybe you know the answer.

    I had a C# class registered as a COM object and I was trying to load it using automation in C++.  The load was failing because mscoree couldn’t find my C# dll, but fuslogvw.exe didn’t show anything.  My question is: is fuslogvw supposed to show assembly binding failures that happen as part of COM activation?  (I’m using CLRv2 on XP.)

    I’ve fixed the underlying problem now, so this isn’t important.

  6. Carlos says:

    Thank you, I used a custom log path and that fixed it.

  7. PhilW says:

    I think SxS COM with manifests is one of those "well kept secrets" that should be more well known. I use it whenever I can and encourage others to do the same. Some more info here too ;=)

  8. nin says:

    45151bjgvuguojhipkm[‘ol,p;, hvb jh

  9. Kurbli says:

    Jon Galloway írta IE7-Standalone-Launcher-updated-for-RC1.aspx tárgyú bejegyzésében, hogy a…

  10. Sxs activation model is built on top of Actication Context. To create an activation context, use the

Comments are closed.

Skip to main content