MSP files can be used to create very complex updates which will upgrade from multiple previous versions, but the rules and vagaries of such a task are beyond the scope of this article, which focuses more on the average sysadmin or packager’s need to create and distribute a minor update. Furthermore, I haven’t created a significant number of patches, nor have I plumbed the depths of what the Wise Package Studio Patch Creation tool is really capable of. Ergo, caveat emptor.
When to Use a Patch File
Patch files (extension .MSP) are best used for the following conditions:
- The original MSI is already installed on the target workstations.
- You only have minor registry changes or newer versions of already-installed files.
- There are few or no new files, features or components to add to the installation.
Before you continue reading this tip, take a look at the Patch Creation tool documentation that comes with Wise Package Studio. This is probably located in your installation under the Wise Share Point\Workbench directory, e.g. “C:\Wise Share Point\Workbench\Tool – Patch Creation.htm”. Read it through once even if you don’t understand it all, because I’m not going to repeat it here.
- Locate the previous/installed version of the MSI or WSI (preferably the WSI) you wish to update, and make a copy.
- Edit the copied WSI or MSI with the changes you want. But keep in mind the following:
- You should not change any existing components and features, including setting different keypaths, adding files, or moving components between features. The only exceptions to this are updating registry values and newer versions of files already in the components.
- If you must add new files, create a new top-level feature and its child component(s) to contain the new files. Remember the component name, because you’re going to need it for the command-line.
- Go to the Setup Editor pane and the Product tab. Select “Summary” in the tab list and double-click the field named “Package Code”. In the Summary Details dialog that opens, click the “Generate” button to create a new Package Code.
- Now save and recompile your update package.
- Close Windows Installer Editor and go back to the WPS Workbench, and run the “Patch Creation” tool.
- Choose “Create a new Patch file” and hit “Next >” to continue.
- At the “Specify Previous Versions” dialog, browse to the old/installed version of your WSI or MSI and add it. If you have the WSI, choose it; otherwise, the program may ask you to create an Administrative Installation first (follow directions if you must).
- In the “Upgrade MSI path” dialog, browse to the new updated version of your WSI or MSI that you just created. Fill in any additional information requested, and note the “Advanced…” button for more control over your configuration.
- At the “Compile Patch” dialog, specify the full path and name of the MSP file you want to save, and Check the “Create a log file” option (you should look over this .LOG file in the same directory as the .MSP after the wizard is done, just to see how the program did). Note that if you suspect you need to check some of the other options (e.g. “Allow Product Code to differ between the upgrade and previous versions”), you may be better off creating a proper upgrade MSI rather than an patch file (at least until Windows Installer version 3.0 delivers on its promises to make patches a easier and more stable).
- Click “Next >” and wait. And wait some more… this could take a little while, because the patch wizard must sort through the packages to find all the changes.
- Create a shortcut to launch the patch installation. Important: Double-clicking the .MSP file will not patch an existing installation; it will only update the cached copy of the MSI database. Use this command line instead:
msiexec /p patch.msp REINSTALL=ALL REINSTALLMODE=omus
If you stubbornly insisted on adding files or features in your patch, you need to change your command line some or it will not work as you suspect. In this case, you do not want to reinstall “ALL”, because it will only install the components which were installed the first time; instead, set REINSTALL equal to the top-level feature (most likely “Complete”) that was in the original package, and add ADDLOCAL or ADDDEFAULT with your new feature so it is installed as well, like this:
msiexec /p patch.msp REINSTALL="Complete" ADDLOCAL="NewPatchFeature"
- Some people find it easier to distribute patches in a more “foolproof” custom executable that contains the proper command line internally. One way to create this is with InstallShield’s free PackageForTheWeb tool, available at http://www.installshield.com/pftw/. YMMV.
- Test, test, test. Try your new patch with the original MSI already installed. Try installing it simultaneously with the MSI. Try it through your distribution method (AD, SMS, Tivoli and such). Then try it again just to be sure.
In the Future…
Microsoft is promising improvements for patching support in Windows Installer version 3.0, which I am beta testing now. This should include fixing the funky behaviors of patches common to older version of Windows Installer, and adding support for multiple patches and such. This could, of course, make this article irrelevant or incorrect… but we’ll see when it comes about.