I have read that it is not a good idea to deliver a major upgrade as a patch. Indeed I had a lot of problems when trying to do this. Here are the steps I followed to create a test patch that worked:
- You must of course set up the major upgrades to work correctly first without using a patch. This involves sharing upgrade code between setups, but change version number, package and product code. Plus setting all the necessary settings in the Upgrade table and adding a SecureCustomAction property.
- Be very meticulous that you never install the same file multiple times with different component id's. This is of course a general windows installer requirement, but it is particularly important when dealing with major upgrades since they will "uninstall each other". Hence if they share files, but assign different component codes to them, the setups will interfere with each other and files will be missing after upgrade.
- Ensure all files with localized content, but same name are installed to different sub folders of your installation directory. So German help file would be INSTALLDIR\GER\Help.chm, English help file would be INSTALLDIR\ENG\Help.chm. This ensures that the file the patch "ecounters" on disk during patching will match the language version it is "expecting".
- Schedule the removeexistingproducts action to run towards the end of the installexecute sequence (otherwise a patch won't work at all since the files you want to patch will be uninstalled before the patching operation starts).
To ensure that all files that already exists on disk are overwritten / updated during patching, set the REINSTALLMODE to amus in a custom action if IS_MAJOR_UPGRADE is defined. Never use amus (which will downgrade higher version files), use emus if need be (replace same version or older verson files) - even that can be dangerous and trigger file protection warning if files are installed to system folders (which can happen-without your knowledge if you use merge modules). Previous Windows versions (2000 / XP) just restored the higher version file from its dllca che (Windows File Protection), newer versions of Windows (Vista onwards) actively trigger file protection warnings since the files are protected by ACL (Windows Resource Protection). This may yield a full runtime error.
- If you use ANY dynamically linked components, ALWAYS ensure that you set the "patch optimization" in the release wizard. If you add new dynamically linked components, ensure that you point the patch optimization to the most recent version of your older MSI files. This is CRUCIAL to ensure that the major upgrade does not remove files that exists in both the older and newer version of the application. If you do not perform this step you will almost certainly experience strange results after patching (files missing, files not updated etc...) since different component id's will be given to files with the same name in the old and new setup. In my experience this is probably THE most important reason why a major upgrade patch might "go crazy" and do unexpected things during installation.
- If you deliver different editions of your setup, create a different patch per edition, don't try to patch all editions with a single patch.
Edited by Glytzhkof, 23 September 2014 - 12:15.