MSP vs. MSI packaging. Which to use for patches?

Question

Currently I am working on a project which is deployed by using an MSI package. To patch the program, we just deploy another MSI installer package opposed to an MSP. Is this an effective/efficient way to go about this, or should we be deploying an MSP patch package instead? I have had experience with MSI but not MSP. How would I also go about creating an MSP patch? I trawled through the internet and cant seem to find anything.

Thanks in advance!

Zoophobia

Answer 1

The choice is really up to you, though MSP provides smaller file sizes which can be advantageous for large projects. In particular, this MSDN article says:

Servicing applications by delivering a Windows Installer patch, rather than a complete installation package for the updated product can have advantages. A patch can contain an entire file or only the file bits necessary to update part of the file. This can enable the user to download an upgrade patch that is much smaller than the installation package for the entire product. An update using a patch can preserve a user customization of the application through the upgrade.

This page provides advice on using the MSIMSP utility to generate an MSP patch file given the old and new MSI packages.

Thistle

Answer 2

Patching is very complicated and difficult to work with, and quite unreliable if you don't follow proper MSI practices.

I use it only when I have to in order to achieve a fix that isn't possible to deliver in any other way. An example of this is if a product's uninstall sequence is broken so that the uninstall doesn't complete but goes into rollback. Then I patch with a minor upgrade to fix the error in the installed product, and then uninstall it. Most of the patches I have made this way was made with Wise Package Studio - and they worked well.

I also use patching to deliver very small fixes to released products. Typically just a single file or two with some urgent hotfixes. Any complex software release may urgently need such a patch a few weeks after main release as urgent issues are discovered in the wild and a quick fix is desired. This is to prevent large downloads for end users. And in these cases I always enable "include whole files" in order to prevent bit-level patching which is notoriously error prone.

Many people want to use patching to deliver small daily updates to QA-testers. Forget it. It is not worth the risk, certainly not the effort and saves practically no time whatsoever unless your testers are overseas. If you do need to patch for QA-testers, do not ever use bit-level patching as this will fail if they have messed around in the installation folder - which good QA-testers are likely to do.

If you need to make patches for a released product, do make sure to make good use of any available QA-testers, and have them run through patching on different platforms, upgrading from different versions, different languages, etc... It's very hard to get right. It is also adisable to not target too many prior releases with a patch since this tends to make things complicated quickly.

Overall: keep in mind that patching is designed for hotfixing. The linked article might be worth a read if you are researching the use of patching for your product. It is a bit messy, but describes several MSI patching obstacles.

Cowie

+1, providing additional information when a question has been solved. Thanks :) – Zoophobia

Trench report Jacooobley :-). – Deeplaid

@Glytzhkof Then, what do you usually use for updaiting files instead of msp? I want to know. – Phylloid

Use regular minor or major upgrades, preferably the latter. Patching is just a delivery method for these sort of upgrades anyway, they are just more error prone. – Deeplaid