PDC05: Day One (Versioning & Servicing in VC++)

At first I thought this was going to be another presentation with a topic just outside of my area, but boy was I wrong. The topic "Versioning & Servicing in VC++" by Nikola Dudar was focused around the new deployment story for Microsoft. Now, I am no expert in deployment, but the people who were experts got hot about what was said. There are presently three ways to deploy DLLs to the Microsoft platform:

• System32 (or path)
  The oldest technique, and the very source of the phrase "DLL Hell," is the first option. Windows redistributables are all installed in a common area, which can lead to other packages replacing your stable versions of say MFC42.DLL with a different version. This is the least preferred option for installation.
  
  
• App-Local
  This technique allows ISVs to install even redistributable DLLs into the application directory, effectively ignoring the shared versions elsewhere. This means that no other application will overwrite your stable versions of the DLL and cause you problems.
  Nikola told of the recent GDI+ problem and how, since it was deployed app-local by so many vendors, servicing it was next to impossible for Microsoft. This is where the story really heats up later...
  
  
• Side-by-Side
  The newest plan from Microsoft for recent operating systems only. This technique has specific versions of a DLL installed in a common location and applications contain a "manifest" which says "load this version of this DLL set." It is probably a good approach, but it is somewhat related to DLL Hell.
  The VC++ 2005 compiler includes some new tools and mechanisms to make Side-by-Side much easier to handle as a deployment story.

The tale heats up when Dudar mentions that once developers upgrade to VC++ 2005 App-Local deployment will no longer be: recommended, supported, or within the terms of the VC++ 2006 EULA.

The question and answer period went on for about an hour with a back and forth about Microsoft's effective ban on the App-Local deployment, which was the preferred strategy until very recently. The final analysis is that Microsoft promises not to make breaking changes to shared redistributable DLLs. While I wish that were true, I suspect ISVs are now stuck with this deployment problem just to make Microsoft's servicing problem easier. The discussion continued until 6:30pm, when all parties gave up out of a desire to eat.