What to put into a Windows Installer MSI directly vs. a wrapper/boostrapper?

0
votes

Background

I'm currently triaging migrating an existing non-MSI setup to a Windows Installer based solution. The current solution is written in InnoSetup and I very much like it, however, customer IT departments start to require MSI, and where they do so, it is often the case, that many/some of the prerequisites and scripts we include in our setup.exe are not needed for their automated tasks (but, then, some are).

Therefore it seems a pure MSI wrapper doesn't make too much sense here, so I'm looking at (multiple?) MSI files plus a boostrapper.

Prior knowledge

I'm good an InnoSetup, but I'm just starting to read into the Windows Installer technology.

Question

As far as I can tell, for any multistep / "complicated" setup requirements including prerequisites and stuff, using just a bare MSI file is a no-go. (As evidenced by the existence of all the different boostrappers, including the one bundled with WiX, Burn)

Therefore, I would need to split our existing monolithic setup into several steps, some of which (mostly those that install our files) bundled into MSI databases and some of the steps just "scripted" in the bootstrapper.

And here is where I really could use some prior experience regarding setup packages: What parts of a (chained) setup go into the MSI package(s) and what part goes into the bootstrapper?

Should all the (normally visible) UI reside in the bootstrapper or do you put some of it into the MSI files?

How "dumb" should each MSI file ultimately be? That is, if using a bootstrapper and multiple MSI files anyway, should any individual MSI file contain any optional parts, or should all the options be factored out into separate MSI files (that just check for the existence of their respective prerequisites, but contain no logic to install them)?

Basically, the application (suite) needs to support a click-through average user scenario where the setup handles everything and for corporate clients needs to be able to be split up into MSI files that only contain our stuff minus dependencies like the .NET runtime, SQL Server, ... that'll be handled by the client's corporate IT and our software MSIs will be deployed by the client IT automagically.

So, should all the glue and dependency scripting go into the bootstrapper and only use very simple MSI files? Or should some "logic" go into (some) MSI files?

2
wixwindows-installerinstallationburn
robmensching.com/blog/posts/2009/7/14/lets-talk-about-burn – Martin Ba

2 Answers

1
votes

Short-ish answer:

When there are multiple MSI files it is normal for the UI to be handled by the Burn bootstrapper because you do want to see combined progress, not all the separate MSI UIs. You also should set up appropriate rollbacks of more than one MSI in the event of a failure of one if you are really packaging several MSIs as a product, so if one fails they all need backing out.

The bootstrapper contains detection logic that determines what needs installing, and can install prerequisites like SQL, NET etc, but must not otherwise change the system.

The MSI files contain all the files, service installation, COM registration and so on that is appropriate for the files being installed. Any custom action code you use that alters the system must be in the execute sequence, deferred, and have a corresponding rollback CA to undo whatever it does. The MSI should be capable of being run independently to install its content - I've found that to be a useful guideline. The MSI files will be installed without their UI, so ensure that they can be installed silently with parameters passed as property values on the command line, including install location.

1
votes

Hard to answer this in brief. Do use Burn or a similar bootstrapper, and leave runtimes with their own deployment solution as a separate file to run - and run in silent mode by default.

  • For home users you should install everything without too many questions to avoid confusion.
  • For corporate deployment you should deploy only what is needed and make it clear what each included deployment file is for:
    • Write a one page PDF with deployment instructions describing what every file does and what runtime it relates to. Call it "DEPLOYMENT README.TXT" or similar. This is the best way to get your application approved for corporate deployment. It can be tiresome to analyze this.
    • Application packagers in the corporate environment will analyze the prerequisites and determine if your application will work well with their standard framework packages. These standard packages will be set as a prerequisite in the distribution system.
    • Document in particular what .NET framework version is needed and other runtime requirements in detail.
    • Don't install windows hotfixes, msiexec engine updates or .NET framework runtimes automatically. Document them as prerequisites in your text file. These runtimes are tightly controlled in corporate settings and they are deployed by customized corporate packages.
    • You can include merge modules of simple runtimes in your MSI, they can be easily removed by the application packaging team in the corporate setting.

This answer didn't get terribly good, but I am out of time. Perhaps check this answer as well: MSI Reference Counting: Two products install the same MSIs