A customer had a program that loaded two DLLs,
let's call them
Both of those DLLs use a common helper DLL called
The catch is that the two DLLs want to use
different incompatible versions of
The two DLLs
B.DLL reside in
separate folders, and each folder has a corresponding copy of
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
B.DLL to use their respective
They suspect that some magic with activation contexts and manifests
might do the trick, but they didn't have the expertise to figure out
(And remember that
A.DLL came from a third party and
cannot be modified.)
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" /> </assembly>
You don't have to make any changes to the code
When you try to load
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 "
C.DLL is not made visible to other DLLs
(unless they specifically ask for it with their own manifest),
so when the program loads
it will ignore the
copy and look for
the traditional search path.
The customer confirmed that
adding the manifest to
Note that the manifest declaration applies to DLL dependencies
B.DLL is loaded.
B.DLL performs a
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.