'How to disable a particular CustomAction for previously installed version during an upgrade installation with MSI database?

I have a package whose previously installed versions contain a series of poorly designed custom actions: they do stuff that can be done out of the box. Thus I'm removing those for the future versions.
A series of bugs is casued by a condition for those custom actions - they all run the second time during an uninstall step during an upgrade. In order to circumvent the undesirable behavior I'd like to supply a Custom Action which modifies the database of a previously installed application if one was detected.

Given an application name, version and custom action name, how can I disable it for an uninstall step during a custom action on upgrade?

My attempt to ammend the Custom Action condition failed when I run my code within a C++ custom action during an upgrade installation: MsiOpenDatabaseW throws access violation when executed within an msi custom action
Basically I am using MsiOpenDatabaseW to modify the cached msi database. It works when running within a standalone executable, but causes access violation within a Custom Action.

c++windows-installer


Solution 1:[1]

You need to amend the 'Condition' of the InstallExecuteSequence/InstallUISequence for the Custom Action of the cached (installed) MSI. An example can be found here, which searches for the cached MSI based on the ProductCode and amends the Condition of a Custom Action in the InstallExecuteSequence:

https://www.alkanesolutions.co.uk/2012/12/08/editing-msi-files-in-the-windows-installer-cache/

Solution 2:[2]

EDIT: Some colleagues wrote a free guide on installation testing. Maybe it will be useful in the future, to avoid such costly mistakes.

A simpler solution I recommend is to manually fix the condition on your machine and rebuild the MSI.

Then take this MSI and include it in the next version of your application, and run a custom action to re-cache it, before the RemoveExistingProduct standard action.

msiexec /fv <path of the fixed msi>

This way, the installer with the wrong condition is re-cached before the upgrade is triggered and you don't need to write code that actually modifies the cached MSI dirrectly

Sources

This article follows the attribution requirements of Stack Overflow and is licensed under CC BY-SA 3.0.

Source: Stack Overflow

Solution Source
Solution 1 Captain_Planet
Solution 2

Related Questions