Before You Create Your Upgrade, part 2

[If you haven’t already read Part 1 of this article, I’d suggest taking a look at that first.]

Part 2: Deciding on your Upgrade Methodology

With Windows Installer, you have 2 choices for upgrading MSI-installed software: patches (.MSP files) or “upgrade” MSIs. But for either of these methods, you’ve got a few reasonable choices…

Small Update   Minor Update   Major Upgrade
  • MSP Patch File
  • Reinstall-in-Place MSI Upgrade
  • MSP Patch File
  • Typical MSI Upgrade
  • Uninstall-First MSI Upgrade
  • Typical MSI Upgrade

Of course, there are unreasonable choices you could make (say, trying to make an MSP do a major upgrade), but I won’t suggest those here. And to further complicate things, not all of those listed are really going to work well for repackaging tasks, either; for example, if you did a SetupCapture of the app for your first install and want to do another capture with the new version for the upgrade, your choices are limited because the components are simply not likely to line up (nor have the same GUIDs) the way they did with the first snapshot package.

The Four Upgrade Methods

Decide on your method before you begin working on the upgrade; it could save you a lot of time. Here are summaries of the four methods I’ve listed, as well as some points to consider in the decision-making process.

MSP Patch File
The idea of a patch file for an installed MSI is great-however, until Windows Installer 3.0 is a reality, I personally don’t think MSP patches live up to the expectation. Advantage: creates a very small MSP file which includes only the changes required to update the MSI, which might be good for Internet downloads. Disadvantages: with anything before MSI 3.0 you need to do a complete reinstall of the application in order to install the patch file, which can be a huge waste of time for small patches on large installations; also, MSPs aren’t so great for adding new features, components, and such-better save that for MSI upgrades.
Reinstall-in-Place MSI Upgrade
If you only need to make a minor fix but the MSI has already been installed on some of the client systems, you can simply make the changes in the original MSI and do a re-install on the target workstations using the command line “msiexec /fvomus updated.msi” (the ‘/f’ for the reinstall, ‘omus’ for the usual reinstall options, and the ‘v’ to re-cache the MSI from the new source). However, note that (a) this is not a good way to add files, features, etc. and (b) the reinstall and re-cache can be buggy (but no one knows why).
Uninstall-First MSI Upgrade
Possibly the simplest to create, in this method you simply create a full MSI with the new version and add a custom action early in the sequence to uninstall the old version if it exists on the target machine. Sounds easy, right? There are disadvantages: (a) end-users are likely to lose their custom settings when the uninstall cleans up, and (b) this won’t work for uninstalls that require a reboot, or leave around in-use files that will need to be installed with the new version. Then again, if both your original and your updated package were made from a SetupCapture, this may be your best option.
Typical MSI Upgrade
For developers who have prepared both the original/old MSI and the new/upgrade MSI with the same components, features, etc., this is the perfect and sensible solution. Wise Package Studio (or InstallShield AdminStudio) can help you make an intelligent package which can upgrade in place any existing features and components. When some of the components haven’t changed at all, then they will remain just as they are; for those components which have new files, they will be upgraded in place; and of course new features and their associated components will be installed as assumed.
The problem for repackagers is that for the upgrade-in-place to work correctly, the Component IDs and such have to line up exactly-you can’t have two different components install two different versions of the file in the same place, or the self-healing will go nuts. WPS tries to help you out in this regard with the UpgradeSync tool, which can do a lot to automatically align the Component IDs and such; however, it will still leave you with a list of things which need to be fixed by hand, and this process will involve some thought, investigation and work. But if you make a clean upgrade package, it may be worth it.

In the documents to follow I’ll attempt to outline the process to create an upgrade package using the above listed methods.