I am still looking for a solution or at least some guidance, even
though I agree that this is outside of normal good practices. – jJack
1 hour ago
I don’t have access to my deployment tools, but I will try to provide a perspective. Since I don’t fully grasp all aspects of what you write it will be generic comments. I hope it has at least something to do with what you are asking. It turned into a blog as I wrote.
To me an MSI patch is effective for 2 basic scenarios:
- You fix an error in the uninstall sequence of an installed product with a minor upgrade patch.
- You deliver a minor upgrade patch for a couple of files as a “hotfix” for a released product that might be huge and time consuming to reinstall.
For these two purposes I have used MSI patching effectively professionally several times. In every case there was no other good fix. Patching IMHO is for “hotfixing” – it is what the whole technology is designed for, not for deployment of frequent, incremental updates. Delivering 96 file updates is NOT hotfixing.
A Patch is a Working Upgrade: Remember that patching is just a more compact delivery mechanism for an upgrade that already works. It can be a major, minor or even small update, and each one will work differently. Before you do anything else at all, make sure you test your actual full upgrade MSI before attempting to package it as a patch. This is the best advice I can give you. All effort spent on patching is wasted if the full upgrade isn’t working correctly. And yes, this includes install, uninstall, and upgrading in all interactions before making the patch itself. This is perhaps the most common patching mistakes of all.
Several obstacles exist preventing the uninstall of a patch. There are dozens of technical issues that may result in uninstallable patches (recommended read). This is a huge problem at times, since a patch that has deployed a hotfix may be found defective and hence should be pulled back entirely. In my view this is one of the core uses of a little patch – deploy a quick fix that can then be rolled back.
Patching & Custom Action Conditions: to me, one of the worst aspects of patching is that custom actions in packages may not be conditioned properly to NOT run when a patch operation is being performed as opposed to a normal installation. A patch features patch-specific properties such as PATCH and MSIPATCHREMOVE. Use these conditions on custom actions to make them run or not run during a patch depending on what is necessary. Be careful with the conditions on custom actions, they are complicated to get right. Here is a “MSI Conditions Cheat Sheet“ to help you. I have not tested these conditions – testing is the only guarantee.
Some further patching advice:
- I would forget major upgrade patches entirely. I have tried them, and will try them again, but they tend to be less than ideal. An absolute requirement for a major upgrade patch to work is that RemoveExistingProducts is placed after InstallFinalize in the InstallExecuteSequence. The reason for this is that otherwise the files are uninstalled before the patch package tries to patch the existing files. Quite catch 22.
- A minor upgrade does not uninstall the existing installation, but rater re-caches a new MSI file to use for maintenance and uninstall operations. This means the patch can fix the uninstall sequence before it is run – one of the good patch uses that I listed above. In fact if the minor upgrade works, a patch may not be necessary at all. Just use the minor upgrade unless your MSI file is enormously big and you want to deliver a small “hotfix”.
- If you need to include files in your patch, I recommend enabling “include whole files“. Otherwise bit-level patching is done, and this is unnecessary complexity (unless your binaries are enormous). I am also not sure how bit-level patching works with signed files and digital signatures.
- Include only what you need in a patch. Add no files or settings that are not required, and you can make a reliable patch. Avoid adding custom actions if at all possible.
- As already mentioned: be aware that a patch uses the same InstallExecuteSequence as a regular install, but you can condition custom actions differently with patch-specific properties such as PATCH and MSIPATCHREMOVE. Use these conditions on custom actions to make them run or not run during a patch depending on what is necessary.
- Component referencing must be 100% correct for ANY type of patch to work. No exceptions.
- Minor upgrade patches must be run with the proper msiexec.exe command line to work unless delivered via a setup.exe / update.exe.
- Third party merge modules frequently cause patching problems in my experience.
- “Version lying” as they call it – the black art of ensuring files are always updated by adding a different version in the MSI file for the file on disk seem to cause patching errors.
- A patch will show the same GUI as the main install. In my opinion this is erroneous design. Custom actions in the GUI could mess up the patching process (should you accept new user input for values for a patch?).
- I believe each patch should be cumulative – replacing all previous patches. I never got this working properly back when I tested several patches installed in series and sequence. I concluded, for many reasons, that this was a futile patching approach to begin with. I had problems exactly along the lines of what you describe with the patching families, target releases etc… A patch isn’t too smart, it is just a complex bundle of a few files trying to find the product it belongs to.
The obvious thing to conclude is that I really don’t recommend that you go with this patching approach, even when asked to. However, I read this thread which seems to indicate successful patching for someone who has converted to using WIX instead of Installshield. You should check out the CodeProject link too.
As to your deployment scenario – I don’t fully grasp all aspects of it, but it sounds like the developers want patches to convert a live application into the current QA version via a patch? I would never go along with this, or the scenario must be different from what it sounds like. Totally wasted effort to create a patch when you already must deliver minor or major upgrades in the first place – they are more than enough to deliver software for QA. You could use the dev-branch to deliver a separate MSI and then create a few patches now and then to test that the product is patchable, but I would never use patches to deliver installers of your product internally. I don’t know if that is what you are asked to do.
Work with minor and major upgrades – preferably the latter for non-patches, and deliver a patch when you really need it. If installation duration is an issue, you could just schedule a daily major upgrade happening after the nightly build is complete on all developer and QA PCs? (including killing any running processes required to make the install work). I don’t know if I am totally off track with what your scenario really is.
Check Stefan Kruger’s installsite.org for more upgrades and patching tips.
Check out this well known wix tutorial for upgrades and patches. And MSDN.