Everything you wanted to know about VC++ deployment but were afraid to ask

Posted By: Charles | Jan 2nd @ 11:32 AM

After C++ code has been written, compiled and tested it's now time for figuring out how to deploy it successfully on n number of users' machines and their various configurations... This is no easy task given the number of potential versioning conflicts. Of course, there are ways to do this, many of them automatic in nature, but which way is the best way? How do the various methodologies of delploying exes and dlls on machines stack up? How does it all work? Deployment is one of those things that many of us take for granted, but George Mileka and Ben Anderson of the Visual C++ team spend much of their time thinking about the process of deploying code to any number of machines so we don't have to. Tune in and learn about the nitty gritty of VC deployment. There is plenty of whiteboarding in this one so be sure to put your propeller caps on.

Tags: C++, Deployment

Rating:

Views (19,029)

Comments (19)

Downloads

sakisp

Interesting but overcomplicated guidelines that nobody knows, reads or follows.
Thanks anyway Smiley

Charles

sakisp wrote:

Interesting but overcomplicated guidelines that nobody knows, reads or follows.
Thanks anyway

Interesting point of view. I don't agree, however. Follow these guidelines! They will save you from much grief... Smiley

sakisp

Charles wrote:

Interesting point of view. I don't agree, however. Follow these guidelines! They will save you from much grief...

I do that Charles whenever is possible, but I was not talking about me.
Most of the software industry "big-names" (not to mention 99% of shareware vendors), ignore these guidelines when designing their products deployment.

graboy

Sorry but you've managed to make the process of distributing .dlls harder and less reliable than it ever has been.

(SXS will likely join the registry and UAC in the legendary "it sounded good on paper" pile.)

odujosh

sakisp wrote:

Charles wrote: Interesting point of view. I don't agree, however. Follow these guidelines! They will save you from much grief...

I do that Charles whenever is possible, but I was not talking about me.
Most of the software industry "big-names" (not to mention 99% of shareware vendors), ignore these guidelines when designing their products deployment.

Wow you must be a busy guy working with so many companies to make such generalizations. So do you hop companies every week. Or are you making something up to have a point. I vote for the latter.

giovanni

Just out of curiosity, what approach deos Mac OS X uses (I know they don't have dlls, but they still heave lilbraries, etc.)?

Do they link everything in the binaries? How are updates taken care of in that case?

FluffyDevilBunny

MacOS does use dlls or sos. It gives the appearance that they don't exist because the application you are clicking on is actually a directory with an extension of .app. Everything the application depends on is in the directory so when you drag it around places, everything goes with it. As for shared dlls, they are stored in the library directory. The application contains a manifest that tells it which libraries it relies on. Its all very simple.

DouglasH

FluffyDevilBunny wrote:

MacOS does use dlls or sos. It gives the appearance that they don't exist because the application you are clicking on is actually a directory with an extension of .app. Everything the application depends on is in the directory so when you drag it around places, everything goes with it. As for shared dlls, they are stored in the library directory. The application contains a manifest that tells it which libraries it relies on. Its all very simple.

so in theory MacOS can still suffer from dll hell unless the library directory stores multiple versions of the Library.

Douglash

giovanni

FluffyDevilBunny wrote:

MacOS does use dlls or sos. It gives the appearance that they don't exist because the application you are clicking on is actually a directory with an extension of .app. Everything the application depends on is in the directory so when you drag it around places, everything goes with it. As for shared dlls, they are stored in the library directory. The application contains a manifest that tells it which libraries it relies on. Its all very simple.

Well, it does not look substantially different from Windows...