Re: MFC Static vs Dynamic Link

"RB" <NoMail@NoSpam> wrote in message
news:uO7i8Yn4KHA.1424@TK2MSFTNGP04.phx.gbl...


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