15 replies to this topic

[Glytzhkof]

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.

[Stefan Krueger]

Excellent advice. A question however: usually I wouldn't recommend setting REINSTALLMODE=amus because it may cause a downgrade of shared files (since this setting is global to your setup, you may downgrade system files for instance). Wouldn't the default of omus be better?
Also I'm not clear whether that custom action to set REINSTALLMODE should be in the old or in the new version, and where that IS_MAJOR_UPGRADE property is coming from (UPGRADINGSPRODUCTCODE may be a better property)

[Glytzhkof]

I set the REINSTALLMODE to amus in order to ensure that all files are properly updated during the patching process. I used to have problems that dynamically linked files would not be properly updated. I realize that this setting is "global to the setup" and will apply to all features. However, I don't install files anywhere else than the installdir folder. Would the amus setting also apply to merge modules? I suppose an alternative would be to statically link a "version flag file" in the dynamically linked components (to force installation of the dynamically linked files).

The IS_MAJOR_UPDATE property is an Installshield specific property that for some reason seem to be set earlier than UPDATINGPRODUCTCODE. I believe it is sufficient to set this property in the newer setup.

[Glytzhkof]

Stefan, you got me nervous :-). I set the reinstall mode back to omus. At some point I need the MS XML merge module (4) and SOAP for this product, and if the reinstallmode also applies to these merge modules that does not sound good. I guess I will just have to live with the silly file versioning rules from windows installer (I can probably zap the unversioned files I need to force replace in a custom action early in the execute sequence during patching).

But as to MSI, why on earth can't you define the reinstallmode per feature? Would make things much more flexible I believe.

 

December 2017: Nothing has changed. REINSTALLMODE=amus is still dangerous and can cause several problems:

 

1: Downgrading of shared files.

2: Mismatched or inconsistent file versions - a total mess, some new and some old files - as several packages all using REINSTALLMODE=amus may install out of sequence (older packages installed after newer ones) and thereby downgrade some files while other files may be upgraded (if they were not present in the older packages). People often use this "feature" to ensure a consistent version estate by force overwriting everything, but as you see they achieve the exact opposite: a totally unpredictable mix of new and old files.

3: Overwriting of data files that have been changed after installation. Possibly also if they are marked permanent and even do not overwrite.

 

Those are just a few off the top of my head. There are several others that I can't recall at the moment.

Edited by Glytzhkof, 22 December 2017 - 00:39.
Elaborate why REINSTALLMODE=amus is really, really bad to use.

[Stefan Krueger]

REINSTALLMODE applies to the final .msi package, including any merge modules.

being able to define the reinstallmode per feature or per component would be indeed be useful. I recommend you submit this as a feature request to Microsoft.

[Glytzhkof]

More on the adventure using major upgrades for patching. I had a problem that all the features would show up unselected if the user chose "Custom" in the setup type dialog. The cause of the problem was that the "Preselected" property was set - don't ask me why it was set, but it was. Adding a custom action to "clean out" this property and condition it to only run during a major upgrade appeared to solve the problem (I would strongly recommend to condition this custom action to only run during a major upgrade since cleaning out the property is not a good idea for minor updates).

Here is the tip that I found: http://community.ins...&threadid=81429

[Glytzhkof]

I forgot to add that the Preselected property seems to prevent MigrateFeatureStates from running, and this is apparently what causes all features to be shown as "unselected".

[Glytzhkof]

The Preselected property is set during a major upgrade patch because it seems Installshield sets the REINSTALL property equal to ALL during patching (this will cause the Preselected property to be set).

I must be missing something here... Setting REINSTALL = ALL for a major upgrade shouldn't have any effect at all (since the new product replacing the existing product isn't even installed yet). What is up with this? The only effect of this seems to be that new features added to the setup won't be installed.

[Stefan Krueger]

Setting REINSTALL in a msp patch makes sense for small and minor updates, but not for major upgrades. If InstallShield automatically sets REINSTALMODE in a major upgrade patch I guess that's simply because they don't really support major upgrades as MSPs. You should be save removing it.

[Glytzhkof]

OK, thanks Stefan. I will give that a try tomorrow. The REINSTALL = ALL property seems to totally confuse the MigrateFeatureState action (so it sets new features to Installstateabsent).

[Stefan Krueger]

That's true, and actually the expected behaviour (if nothing is installed there's nothing to reinstall)

[Glytzhkof]

I now added REINSTALL to the list of properties I null out, and the migrate feature states seems to correctly default to install new features. Still need to do some more testing though.

 

December 2017: I would not recommend this approach. Don't use major upgrade patching.

Edited by Glytzhkof, 21 December 2017 - 23:12.
Disclaimer.

[Glytzhkof]

It seems to work just fine. Thanks Stefan! I have conditioned the "flush properties" action so that it only runs during major upgrades.

[Glytzhkof]

Did some more testing with major upgrades. It seems it is important to always patch against all previous version of a setup when you use major upgrades as patches. Here is a summary:

[Glytzhkof]

Years have passed, and patching is still difficult. Some updated content here:

• Patching in general: http://stackoverflow.../6104061/129130 
• Patching tips: http://stackoverflow...23450821/129130
• The sanity of patching: http://stackoverflow...24943520/129130

Edited by Glytzhkof, 01 September 2014 - 06:41.

[julienpec]

Thanks you, i've though i would control the patchs making, but i'm having problems at the moment xD

Edited by julienpec, 01 September 2014 - 13:53.