coapp-developers team mailing list archive

["Rittinghaus, Marc" <marc.rittinghaus@xxxxxxxxxxxxxxx>]

Hi,

I'm not sure if it's a problem, either, but the following article on MSDN 
states that a side-by-side assembly should be authored to support the concurrent
use of multiple version in the same process:

http://msdn.microsoft.com/en-us/library/aa374238%28v=VS.85%29.aspx

Your scenario is described at the top of the list. I guess you can expect that the
bunch of assemblies that ship with Windows support that scenario but I don't know
if that will be true for most of the open-source libraries CoApp is aiming at.

Marc
________________________________________
Von: coapp-developers-bounces+marc.rittinghaus=student.kit.edu@xxxxxxxxxxxxxxxxxxx [coapp-developers-bounces+marc.rittinghaus=student.kit.edu@xxxxxxxxxxxxxxxxxxx] im Auftrag von Gordon Schumacher [whiplash@xxxxxxxxx]
Gesendet: Donnerstag, 15. April 2010 06:25
An: CoApp
Betreff: [Coapp-developers] 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...?

_______________________________________________
Mailing list: https://launchpad.net/~coapp-developers
Post to     : coapp-developers@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~coapp-developers
More help   : https://help.launchpad.net/ListHelp