Prev: Property Sheet Problem
Next: CToolTipCtrl pointer or non-pointer member variable
From: RB on 22 Apr 2010 19:47
(Excuse me while I jump in on this thread with my own curiousity question)
David is there another way to prevent DLL hell other than static linking ?


From: David Ching on 22 Apr 2010 20:10
"RB" <NoMail(a)NoSpam> wrote in message
news:uO7i8Yn4KHA.1424(a)TK2MSFTNGP04.phx.gbl...
> (Excuse me while I jump in on this thread with my own curiousity question)
> David is there another way to prevent DLL hell other than static linking ?

Sure, it's automatic for all your projects built with VS 2005/2008 using a
manifest (the default). The manifest built into your .exe gives the exact
version of the C Runtime, ATL, and MFC DLL's, and your .exe won't load if
those DLL's (or updated ones) are found.

But then you have Manifest Hell, because this system has some interesting
problems. Like if your .exe links with a static lib built with another
version of VC++ that requires another version of these DLL's. Then your
manifest will have *both* the library's version and the current Visual
Studio version specified, and when your .exe runs, Windows will look for and
load *both* versions of *the same DLLs* into your process, which not only is
wasteful, but it is incorrect. That's why it is critical that the entire
universe your .exe depends on is rebuilt with the same VC++, so only one set
of DLL's is loaded.

The Powers That Be at MS decided this was even worse than DLL Hell, so for
VS 2010, they *removed the manifesting of the C Runtime, ATL, and MFC
DLL's*. Therefore, you will be playing DLL hell with these again. However,
it does make it easier to do my favorite installation these days: app-local
where you just put all these DLL's into a folder with your .exe. They will
always be used no matter what is installed in c:\windows\system32. So
app-local installs don't have DLL Hell issues, provided no rogue installer
updates the DLL's in your app exe's folder, which I think is pretty much a
safe assumption.

-- David

From: Faisal on 23 Apr 2010 01:16
On Apr 23, 5:10 am, "David Ching" <d...(a)remove-this.dcsoft.com> wrote:
> "RB" <NoMail(a)NoSpam> wrote in message
>
> news:uO7i8Yn4KHA.1424(a)TK2MSFTNGP04.phx.gbl...
>
> > (Excuse me while I jump in on this thread with my own curiousity question)
> > David is there another way to prevent DLL hell other than static linking ?
>
> Sure, it's automatic for all your projects built with VS 2005/2008 using a
> manifest (the default).  The manifest built into your .exe gives the exact
> version of the C Runtime, ATL, and MFC DLL's, and your .exe won't load if
> those DLL's (or updated ones) are found.
>
> But then you have Manifest Hell, because this system has some interesting
> problems.  Like if your .exe links with a static lib built with another
> version of VC++ that requires another version of these DLL's.  Then your
> manifest will have *both* the library's version and the current Visual
> Studio version specified, and when your .exe runs, Windows will look for and
> load *both* versions of *the same DLLs* into your process, which not only is
> wasteful, but it is incorrect.  That's why it is critical that the entire
> universe your .exe depends on is rebuilt with the same VC++, so only one set
> of DLL's is loaded.
>
> The Powers That Be at MS decided this was even worse than DLL Hell, so for
> VS 2010, they *removed the manifesting of the C Runtime, ATL, and MFC
> DLL's*.  Therefore, you will be playing DLL hell with these again.  However,
> it does make it easier to do my favorite installation these days:  app-local
> where you just put all these DLL's into a folder with your .exe.  They will
> always be used no matter what is installed in c:\windows\system32.  So
> app-local installs don't have DLL Hell issues, provided no rogue installer
> updates the DLL's in your app exe's folder, which I think is pretty much a
> safe assumption.
>
> -- David

Hi David,

How does the app-local install solve the above problem( static lib
uses another run-time library) ?
In this case also, both of the dll should be loaded to same EXE.

From: David Ching on 23 Apr 2010 01:35
"Faisal" <faisalm83(a)gmail.com> wrote in message
news:8e89d1ad-b781-4e0f-9488-abb353cef63c(a)n33g2000pri.googlegroups.com...
> How does the app-local install solve the above problem( static lib
> uses another run-time library) ?
> In this case also, both of the dll should be loaded to same EXE.

When manifests aren't used (as they aren't when building with VS 2010), both
the static lib and .exe imports of the run-time will be satisfied by linking
with the import lib of the VS 2010 version of the DLL. (I believe, but am
not entirely sure, that any DLL version created in the static lib by
manifest-aware VS 2005/2008 is ignored when linking with VS 2010.)

-- David

From: Oliver Regenfelder on 23 Apr 2010 03:39
Hello,

David Ching wrote:
> Sure, it's automatic for all your projects built with VS 2005/2008 using
> a manifest (the default). The manifest built into your .exe gives the
> exact version of the C Runtime, ATL, and MFC DLL's, and your .exe won't
> load if those DLL's (or updated ones) are found.

Would a VS2008 build fall back to using app-local dll's if the manifest
is removed from the executable, if that is actually possible?

Best regards,

Oliver
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: Property Sheet Problem
Next: CToolTipCtrl pointer or non-pointer member variable