← Back to team overview

coapp-developers team mailing list archive

Another variant of DLL Hell

 

I'm not sure this is within the scope of CoApp... but I'm not sure it
isn't, either.  I've gotten conflicting answer to this depending on who
I've asked (read partially as "where in MSDN I've looked").

Let's pretend for a moment that I'm writing a plugin - say, a shell
extension.  Now pretend that my shell extension depends on an
open-source library "Foo", so I link against libFoo.dll in
WhizBangShellExt.dll.  This is a brand-new project, so of course I
install libFoo 3.141, the latest version.

Now let's pretend that a user has installed my WhizBangShellExt, but
unbeknownst to me he's previously loaded CrustyExplorer, another shell
extension.  It also depends on libFoo.dll, but it's a much older
application and is no longer supported, so it's installed libFoo 2.718 -
and it's even a different major revision, and therefore has a different API.

My understanding is that for a given process, there can only be one
"libFoo.dll" loaded at a time; if Explorer loads CrustyExplorer.dll
first, it'll get libFoo 2.718, and if it loads WhizBangShellExt.dll
first, it'll get libFoo 3.141 - which needless to say is rather less
than ideal!

Have I been misled here, or is this a challenge that might be facing
CoApp as well...?



Follow ups