Re: C++ Version 6 app using c++ version 8 dll
"Tom Serface" <tom.nospam@camaswood.com> wrote in message
news:19BC347A-170C-43CC-A033-3A4B712F5534@microsoft.com...
Hi David,
You can't really like .NET and not like DLLs. :o)
Heh, I'm finding out I can distribute my simple .NET app using ClickOnce,
and the package contains a total of 3 files: one .exe and 2 manifests. Not
a DLL in sight! What's more, when the user clicks to install your app, if
..NET is not installed, it will download it from Microsoft site and install
it prior to installing your app. How cool is that! :-)
Seriously, I'm not sure I understand this debate. It seems to me that the
best method should be used based on the application being created. If I
know my application is going to run standalone and no other applications
running at the same time will share any of the code then static linking
works just fine. Plus, the MFC stuff is such a thin skin over the SDK you
wonder why they ever had the DLL version. Downloading is sort of moot
these days so I'd probably prefer static linking in that scenario just to
ensure that my entire program got to the user. FWIW, I don't think the
program uses any more or less memory either way so I'm not sure what
"professional" has to do with it. I figure if the programmer got paid,
they must be professional (that's a good IRS definition anyway).
Exactly, I was trying to say (perhaps unsuccessfully) that "professional"
has nothing to do with the size of the app or the number of DLL's. A large
number of DLL's can be interpreted either as power (good) or sloppiness
(bad). Static linking has HUGE deployment advantages that are completely
ignored by the pro-dynamic linking crowd. They are right that if you are
not careful, having multiple instances of MFC and the C-RTL in the same
process can lead to errors. But IMHO, these can usually be worked around
easier than solving some of the deployment problems.
-- David