In case you didn’t know, Windows XP SP2 provides a very cool update feature. It works like this: you have a main product, and the Quick Fixes / Service Packs that are applied to it. When you repair your setup for the main product, all the updates are also applied. When you remove, the cleanup is done for all. And it also looks cool on the Add/Remove Programs screen:
You’ve probably seen it before in Vista, and thought that that was a Microsoft only thing. I really prefer the way it looks in XP. It looks like this in Vista:
The good news is that you can do the same for your software, and it’s actually easy! The trick is to know the MSP format (same as MSI, but for Patches instead of Installers). MSP is a format you’ve probably never heard about, but you use it all the time. Each time you get an update from Windows Update, or a download from Microsoft KB, you are downloading MSP files (within a bootstrapper, but I’ll get to that later). Also, if you have installed any Service Pack provided by Microsoft, you’re also using MSP files. This covers both cases: KB articles are Quick Fixes, Service Packs are Service Packs.
So what’s an MSP file? It’s just the difference between 2 MSI files. For the files to be comparable, their Product Code (Id attribute in Wix’s Product element) must match. They must also have Comments in the Package element and UpgradeCodes on the Product element. The rest is pretty much free, and will count as “differences”, but you shouldn’t alter the Feature tree too much if you want a logical upgrade. Also, it’s recommended that you change the Version number (changing build for Quick Fixes, and minor for Service Packs). You should consider forcing a remove/reinstall for Major Upgrades. Changing version numbers is not mandatory, but it is recommended.
To create your MSP file, then, you need 2 MSI files:
1) The setup that your client has installed in his computer and that you want to upgrade.
2) The setup you would have provided if you could, with fixes to the previous setup.
Both MSI files must have the same name, so to keep them apart you have to place them in different directories. For the directory names, I use “installed” for the first setup, and “upgrade” for the second setup.
The cool thing about this is that you can publish an upgrade for pre-installed products in MSP format, and an install for customers that don’t have the previous version in MSI format.
To create the patch, you need both MSI files to use uncompressed files (compressed=”no” in the Wix file for both). This is not something you’ll normally do, but there is a very practical workaround: extracting both files to their own directories. To do this, you’ll do:
msiexec /a installed\myproduct.msi TARGETDIR=c:\myproduct\installed
msiexec /a upgrade\myproduct.msi TARGETDIR=c:\myproduct\upgrade
This will extract all the files in the setup and new MSI files that are not compressed in each directory. The only gotcha here is that you can’t have any feature with level 0. If the level is 0, the files will not get extracted. In this case, you can safely open the setup with Orca and change the level to 1, or whatever. This change will not render the upgrade incompatible with the previous setup. If the files are not uncompressed where they should, the upgrade will not work.
Now that you have this, all you need is a PCP file. This is a file with information on what you want to upgrade. There is a good sample of this on the Wix Tutorial (http://www.tramontana.co.hu/wix/lesson4.php#4.2), by far the best resource on Wix available. There most important element in your wix file will be UpgradeImage. It contains an UpgradeFile element where you can tell the MSP which files you need to upgrade. The MSP file will contain the delta between the two files by default (making it very small in size), but you can tell it to use the whole file if you want.
Finally, you must run the mspmsi tool. This tool is part of the MSI SDK, and it comes installed with Visual Studio 2008. You can find it at C:\Program Files\Microsoft SDKs\Windows\v6.0A\bin. If your PCP file is called upgrade.pcp, the following line will create your MSP file:
"C:\Program Files\Microsoft SDKs\Windows\v6.0A\bin\msimsp.exe" -s upgrade.pcp -p upgrade.msp -l log.txt
If everything worked ok, you’ll have a new msp file. If it didn’t, you’ll get an entry in the log (log.txt) with a very cryptic error. Most common reasons for an MSP not working are:
1) Putting the wrong path for the MSI files, or not having run msiexec /a. In this case, you’ll actually get an error that makes sense.
2) Not having Comments on either MSI file, or having an apostrophe within the product name or the comments. This is illegal, and should be modified.
3) Non-matching signatures in the MSI files (that is, different Product Codes).
4) MSI files with non-matching file names.
If it worked, you can now open the msp file in Orca to see if the information is correct. To do that, you first open the installed MSI, and then go to Transform –> View Patch and open the MSP file. You’ll get something like this:
Where the green line to the left of the table names means that there are differences between the original and the patch, and the square green box means that the table is new. The Patch file in the screenshot is the most important difference. When the patch run, a PatchFiles action will be run in the Execute Sequence. This action will apply patches for every file in the Patch table. If it is empty, the setup will run but your files will not be patched. When the files in the UpgradeFile elements are not found in the directories where you have uncompressed your setup (with msiexec /a), the table will be empty.
And now you can run the setup! Simply double click the upgrade, and it will be handled by msiexec. If the previous version of the product is installed, you’ll see the Change/Repair/Remove dialog (if available). Clicking on Repair will run your patch. Notice that the setup is running all the actions that a Repair will normally run. There is a PATCH property you can use to know when the setup is being patched, and add or remove custom actions from the patch.
After you install the patch, Repair on any patch or the original MSI will result in your patch being applied. Remove in the patch will only remove the patch (and dependent patches if any). Remove in the MSI will remove all.
The Change/Repair/Remove interface may not be clean enough for your needs, though. You may need the patch to simply show a progress bar and be done with it. You can get this behavior by running:
msiexec /p upgrade.msp /passive
There is a tool called IExpress that’s used to create bootstraps for your setups. If you run IExpress from the command prompt, you’ll see it.The tool is pretty self explanatory. The only thing that you need to know is that you have to input the line I just mentioned in the “Install Program to Launch” step. When IExpress is finished, you’ll have an exe file that will get the correct behavior for you.
So go ahead, and happy patching!
If you need more information, or you want a second opinion, there’s a step-by-step here: http://trentm.com/blog/archives/2007/05/29/wix-and-msp/
You can also use the Wix Tutorial: http://www.tramontana.co.hu/wix
Finally, there’s more info (although somewhat misleading) of IExpress here: http://www.microsoft.com/technet/prodtechnol/ie/ieak/techinfo/deploy/60/en/iexpress.mspx?mfr=true