Question

I am looking to make an installer for a .net application which requires a few other MSI be run. Because of the restriction that you can only run one MSI at a time(honestly, is it 1995?) and my desire to provide configurability of which MSIs to run I can’t just shove the MSIs in a bootstrapper as seems to be the recommend practice. I found a similar question but no joy on the response.

As an alternative is there a .net based installer framework which could be used to customize the install process? I am familiar with IzPack, InstallJammer and NSIS but all of these use non-.net languages and this if for a .net shop who are a bit scared of other technologies.

Answer 1

WiX solves this problem if you’re okay using their UI or doing simply WiX-style UI.

if you want a richer UI experience you need to write a custom bootstrapper. I have solved this problem in the past by writing a customer bootstrapper which presented a unified UI to the user and made the install look like a single package where in reality the install was a collection of MSI files that were run in sequence.

Here’s the general gist of what I did:

• Bootstrapper was .NET managed code. Pros: easier to write. Cons: some system’s didn’t have .NET and I had to have a small unmanaged bootstrapper for my managed bootstrapper that deployed .NET first and then launched the managed bootstrapper.
• Discovered the MSI files (app.config works… my app was more complicated).
• Used managed MSI API to read each MSI files feature list
• Built a single “feature selection” wizard page in .NET winforms that created top-level features for each MSI file and then populated the sub features as read from each MSI file.
• Create MSI command lines based on the feature selection and other options (uninstall, repair, upgrade, etc).
• Created a Uninstall registry key for the “suite” installer and hid the MSI-specific uninstall keys so that there was only a single entry in Add/Remove Programs / Programs & Features.

The devil’s in the details, but it worked and it worked well!

Edit 9/3/2010 with more notes:

Here are some things to consider if you take this approach:

• What is the maintenance mode experience? You probably need to cache your bootstrapper on the system somewhere so that it can open when launched from ARP.
• What about upgrades and uninstalls? Do you allow for upgrades of some MSI’s but not others?
• How do you detect upgrade versus maintenance mode? Pretty much you have to scan all the MSIs and if any of these MSI’s (think “features”) are out of date then you are running as an upgrade, not maintenance.
• Consider partial feature adds… do you support installing only some of the MSI’s? In that case it is possible to get into the upgrade some and fresh-install others scenarios.
• You’ll probably end up introducing the concept of a suite version for the overall suite. Don’t kid yourself… that’s just a human/marketing version… only the versions of the MSI’s matter and only those versions should be used to determine install/repair/upgrade, etc.

Basically, when authoring installs (whether single MSI or composite suite install) make sure you lay out ALL of your use-cases for the entire software lifecycle. It’s very easy to write an installer in a shortsighted manner and then find yourself painted into an unpleasant corner when v2 comes out.

Good luck 😉