NOT UPGRADINGPRODUCTCODE evaluates to true on a major upgrade for custom action

1
votes

I'm creating an installer with an exe that needs to be called during first installation only. On any upgrade the custom action shouldn't be called.

<CustomAction Id="MyExe"
              Directory="INSTALLFOLDER"
              ExeCommand="&quot;[INSTALLFOLDER]MyExe.exe&quot; /arg"
              Execute="deferred"
              Return="ignore"
              Impersonate="no"
             />

and the sequence/condition set as:

<InstallExecuteSequence>
  <DeleteServices>NOT UPGRADINGPRODUCTCODE</DeleteServices>
  <Custom Action='MyExe' After='InstallFiles' >(NOT Installed) AND (NOT UPGRADINGPRODUCTCODE)</Custom>      
</InstallExecuteSequence>

The behaviour I've found is:

  • On first install - Action is run
  • On upgrade - Action is run <-- I don't want it to run here
  • On uninstall - Action is not run

In the MSI installation log I can see an upgradingproductcode is set. I'm not sure how to identify from logs whether it thinks it is installed or not. I tried changing "NOT UPGRADINGPRODUCTCODE" to "UPGRADINGPRODUCTCODE" and then the CA didn't run on upgrade. But it also didn't run on initial installation then.

Am I setting the condition to run on initial installation wrong?

Using Wix 3.11.

1
wixwindows-installer
Please read this answer. What you have to get your head around is the fact that a major upgrade is 1) a sequence of uninstall of old product and 2) install of a new one - with variations with regards to what order this happens in. Hence one setup is an uninstall and the other one is an install. You can use a debugging approach described here to check conditions. – Stein Åsmul
Very often things you run as part of the setup can be run on first application launch. Very much easier in terms of debugging and testing (familiar context, no impersonation, no sequencing, no conditioning, same-source as main application and easy debugging step-through). In short: much more reliable and easier to manage. Benefits for QA teams as well who can use it to test "clean slates" and / or upgrade scenarios. – Stein Åsmul
Thanks Stein. That explains why NOT UPGRADINGCODE wasn't working. In your write-up I saw you mention WIX_UPGRADE_DETECTED and have used this now. Looks like it all works. – Toshio
I managed to add an answer for another question below, so I updated it (since it couldn't be removed entirely) to summarize the above in a sort of "real answer". Note to self: do not answer question with the wrong answers. – Stein Åsmul

1 Answers

1
votes

Major Upgrades & Conditions: Please read this answer. What you have to get your head around is the fact that a major upgrade is: 1) a sequence of uninstall of old product and 2) install of a new one - with variations with regards to what order this happens in. Hence one setup is an uninstall and the other one is an install. You can use a debugging approach described here to check conditions.

Essentially:

  • 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.

Application Launch: Very often things you run as part of the setup can be run on first application launch. Very much easier in terms of debugging and testing (familiar context, no impersonation, no sequencing, no conditioning, same-source as main application and easy debugging step-through). In short: much more reliable and easier to manage. Benefits for QA teams as well who can use it to test "clean slates" and / or upgrade scenarios.

Some Links: