- 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.
-gulp-
Visual Studio Deployment projects, used in a very specific way, is....
-gulp-
pretty useful.
-exhale-
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?
2 comments:
I think the term redemption may be a bit strong. Finding a legitimate use for VDPROJ is nice but you admit it's only good because you don't have to use the bulk of its functionality. It's like saying an old, beaten-up car is still good for scrap - technically it's true but it's still a piece of junk.
I don't want to get too spiritual with the metaphor but basically what I was trying to say was that:
All of the sins could be forgiven if you vowed to never use those `features` again and that what was left, however small, could be saved and have some value.
Sure, I'd never use it at my day job, but for a small project with limited needs ( including bootstrap some prereqs ), it could actually get the job done. It would pass all validation and not have unneeded custom actions. It actually wouldn't be a piece of junk install.
I just never thought I'd say that about VDPROJ.
Post a Comment