How can I specify that my DLL should resolve a DLL dependency from the same directory that the DLL is in?

A customer had a program that loaded two DLLs, let's call them A.DLL and B.DLL. Both of those DLLs use a common helper DLL called C.DLL. The catch is that the two DLLs want to use different incompatible versions of C.DLL. The two DLLs A.DLL and B.DLL reside in separate folders, and each folder has a corresponding copy of C.DLL.

An additional complicating factor is that A.DLL was written by a third party and cannot be modified.

The customer was hoping there would be some way to get the two DLLs A.DLL and B.DLL to use their respective versions of C.DLL. They suspect that some magic with activation contexts and manifests might do the trick, but they didn't have the expertise to figure out exactly what. (And remember that A.DLL came from a third party and cannot be modified.)

Eugene Talagrand explained that you can solve the problem with manifests. Embed a manifest into B.DLL with resource ID 2 that looks like this:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
    <file name="C.dll" />

You don't have to make any changes to the code that loads B.DLL. When you try to load B.DLL, the system will recognize the manifest, and that manifest tells the system to ignore any rogue copies of C.DLL and link B.DLL to the copy of C.DLL in the same directory. Furthermore, this special "B.DLL-specific" version of C.DLL is not made visible to other DLLs (unless they specifically ask for it with their own manifest), so when the program loads A.DLL, it will ignore the "B.DLL-specific" copy and look for C.DLL using the traditional search path.

The customer confirmed that adding the manifest to B.DLL worked!

Note that the manifest declaration applies to DLL dependencies resolved when B.DLL is loaded. If B.DLL performs a LoadLibrary("C.DLL") at run time, then it will need to make its activation context active when it loads the DLL so that the system knows to follow the instructions in the manifest. For more details, you can read more about using manifests to isolate DLLs on Eugene's blog.

Comments (7)
  1. Yukkuri says:

    Manifests have been a lifesaver to us working with a massive legacy VB6 app and associated 3rd party COM components while still running separate releases off the same groups of application servers.

  2. Martin Bonner says:

    Does this work if B.dll is loaded via LoadLibrary(‘\\directory\\that\\is\\not\\on\\the\\PATH\\B.dll”)? When I was trying to solve the problem in the title, I marked C.DLL as “DelayLoad”, and B.dll had a delay load handler which searched the directory containing B.dll for a copy of C.dll and loaded it if present.

    1. “You don’t have to make any changes to the code that loads B.DLL.”

    2. skSdnW says:

      Secure LoadLibraryEx can be done without manifest by using LOAD_LIBRARY_SEARCH_DLL_LOAD_DIR|LOAD_LIBRARY_SEARCH_SYSTEM32

  3. Darran Rowe says:

    I always wondered why DLL redirection was disabled when an application had a manifest. This is definitely much better.
    It is always a shame that SxS stuff didn’t have great documentation and the only real exposure to them most people had were the CRT for VS2005 and VS2008. There is a lot of good here that people just don’t bother with.

    1. Joshua says:

      Yeah, especially because something was *messed up* with VS2005’s c library where another application could hose your copy of it even if you put your copy in the application directory. Somehow it resolved no copies.

Comments are closed.

Skip to main content