Run Wix Custom action only during uninstall and not during Major upgrade
Asked Answered
S

2

2

I am trying to delete a file using a custom action scheduled between InstallInitialise and InstallFinalize standard action.

MajorUpgrade element is used to design upgrades.

However, I want the custom action to run only during uninstall and not during the Major upgrade(this includes uninstall and install).

I have used the following conditions to execute the CUstom action:

  1. (NOT UPGRADINGPRODUCTCODE) AND (REMOVE="ALL")
  2. REMOVE AND NOT WIX_UPGRADE_DETECTED

Is there a way to uniquely detect the Major Upgrade using properties in Wix?

Strangulation answered 28/6, 2018 at 6:7 Comment(0)
E
4

Phil has already answered. I'll just post what I wrote a few hours ago before heading out. The conditions you specify look pretty good to me. Maybe I'll do a quick review of things that are likely to cause confusion - such as what custom actions run when?


Major Upgrades: A major upgrade is really an install of a new application version combined with the uninstall of the old version - with different uninstall scheduling possible (uninstall old and install new, or install new and uninstall old). Hence, during a major upgrade operation, 1) the uninstall sequence runs only for the old setup, and 2) the new setup runs only its install sequence. This is of crucial importance to understand what custom actions runs when and why.

Custom Actions and Major Upgrades: To put it in other words: this sequencing can cause quite a bit of confusion for custom action sequencing, since it could appear that an action runs from the new setup, when it in fact runs in the old setup's uninstall sequence. If you are sloppy with sequencing, the typical error is seeing the same action run many times during the upgrade process - potentially twice from each setup (four times in total - or perhaps even more - I haven't tested that in detail) - if you run the custom action in immediate mode.

No Retrofitting for Major Upgrades: As Phil explains, you can not add a custom action that will run during the old setup's uninstall sequence inside the new setup. That custom action would have had to be part of the original setup, or added via a minor upgrade (which upgrades the existing installation in-place, rather than uninstall and reinstall it).

Important:

  • UPGRADINGPRODUCTCODE is set only in a setup that is being uninstalled as part of a major upgrade. It is not set in the new version being installed.
    • The condition UPGRADINGPRODUCTCODE is hence not true in the installing setup, only in the uninstalling setup.
  • WIX_UPGRADE_DETECTED is set only in setups that are using WiX's MajorUpgrade element that have detected that another version is being uninstalled as part of its install.
    • The condition WIX_UPGRADE_DETECTED is hence true in the installing setup, but not in the uninstalling setup.

WIX_UPGRADE_DETECTED: To go into even more detail, WIX_UPGRADE_DETECTED is strictly speaking not a custom WiX feature - it is a WiX standard or convention for setting the built-in MSI property ActionProperty for the upgrade process. All MSI files supporting major upgrades have such a property, WiX just names it in a standard way. The property is set in a column in the Upgrade table, and it is a property that is set when a setup finds related products - that are lower versions (and hence to be uninstalled) - on the same box during installation.

WIX_DOWNGRADE_DETECTED: Note that in a standard WiX-compiled MSI using the MajorUpgrade element there is also WIX_DOWNGRADE_DETECTED - the property used to list products found that are of higher version than the running setup. These would block the setup in question from installing - in most cases (unless the settings are customized by the setup designer).

The action property specified in the upgrade table can be "anything", but the MajorUpgrade Element "convenience feature" does this for you in an "auto-magical" way that makes sense for most purposes - using the mentioned property names WIX_UPGRADE_DETECTED and WIX_DOWNGRADE_DETECTED. Check the Upgrade Table of your compiled MSI to see how this works in detail. Here is a screen shot:

Upgrade Table of compiled WiX MSI


I wrote this other answer showing how to use another property name (YOURUPGRADEPROPERTY) as "ActionProperty": wix installer update process and confirmation dialog (the linked answer is not a recommendation, demonstration only). Just a link, probably not very useful for you now that I think about it.

Some Links:

Estimable answered 28/6, 2018 at 19:33 Comment(0)
L
3

It's not obvious whether you want to do this in the older installed product (which is presumably already shipped and therefore can't be changed without an update such as a patch) or in the newer upgrade install.

I'll also assume you've looked at the RemoveFile element and it doesn't meet your requirements.

The UPGRADINGPRODUCTCODE property applies to the older product being upgraded and uninstalled. If the file belongs to that installed product and you want to remove it only at uninstall with a custom action in that older install the condition on the custom action would be:

REMOVE="ALL" and not UPGRADINGPRODUCTCODE

but as I said, that custom action would need to be already in the older installed product and there's nothing you can do in your upgrade MSI to fix that.

If you are removing the file from the upgrade then the condition during an upgrade is only:

WIX_UPGRADE_DETECTED

It might also help to say where your major upgrade is sequenced. If it's early (such as around InstallInitialize) then the upgrade is basically an uninstall of the older product followed by an install of the newer product, and that might be related to the removal of the file, if that's what you're seeing.

Lymphocytosis answered 28/6, 2018 at 17:38 Comment(1)
PhilDW Thanks for the detailed explanation. In this case, the uninstall older product is sequenced first and then the Installation of the new product is scheduled. Regarding Remove file element, can we remove a file which was not deployed using the MSI component, but created using deferred custom action. Luckily the product is not yet released, so any modifications to the old setup uninstall sequence can be changed to fix the issue. Please suggest the condition to run the Custom during uninstall considering the above case.Strangulation

© 2022 - 2024 — McMap. All rights reserved.