For years I’ve spoken of the horrors of Visual Studio Deployment Projects:
- Every file and every registry key is always a key file of it’s own component
- ShortCuts are always advertised
- Dependency Scanning is next to impossible to disable
- Custom Action support is horrible ( deferred only )
- No support for MSI concepts such as ServiceInstall encourages Custom Action anti-patterns
- Many more ( Rob Mesnching has an blog post out there somewhere with 100 comments of people’s compaints about VDPROJ and support of Windows Installer XML.
The loathing of VDPROJ was so great that Microsoft is replacing it with InstallShield 2010 Limited Edition. Now I’m going to say something that shook my world view to it’s foundation:
Visual Studio Deployment projects, used in a very specific way, is….
Wow, there, I said it. Go ahead, get your laughs of disbelieve out. I know, I know, Chris has finally fallen off of his rocker. OK, you ready for my defense? Here goes:
I came to realize with my ‘all component data goes in merge modules’ using IsWiX and WiX that essentially every single complaint that I had about VDPROJ stemmed from how it authored component data and exposed custom actions. By abstracting all of this into WiX merge modules and leaving next to nothing in the VDPROJ installer project I am able to build an installer that passes ICE validation and presents no garbage that causes concern for me.
Sure, it’s a fairly limited solution but for a great many projects it’s probably actually is good enough. I get a UI that can be somewhat customized without diving too deep into the details, a bootstrapper that can handle basic prereqs like .NET 3.5/4.0, SQL Compact, C++ runtimes, the ability to define System Searches and Launch Conditions and support for Major Upgrades.
As long as I use a discriminating eye and void using VDPROJ to do anything else like define files and folders, shortcuts, registry and so on, it’s really no that bad.
Instead I use the merge module for everything. Need to author 1,000 files? No problem, just drag and drop in IsWiX and it’s done. Need to give a few of those files shortcuts in the start menu? No problem, write a few Directory, ShortCut and Icon elements and that’s done. Need a Windows Service? No problem, ServiceInstall and ServiceControl elements. Create a Service Account? Configure the Firewall? Find the Visual Studio ItemsTemplates directory? Check, Check, Check.
Sure, I’m going to be limited to one feature ( which makes variation points difficult and resiliency repairs intensive ) and I won’t be able to do quiet a bit of customization but some people probably don’t really need this anyways.
It’s like going to one of those 120+ item buffets at the beach when you are on vacation. If you ignore those 100+ items that junk and stick to the 10-20 items that are good and then bring a few of your favorite adult beverages from home, you’ll probably have a pretty good time on the cheap. I know, bad analogy but I hope it gets the point across.
So there you have it. A somewhat cautious yet positive endorsement for the use of VDPROJ. Who would have thought it?