2

I have a custom action that I want to be executed every time MSI is executed without UI:

<InstallExecuteSequence>
  <Custom Action="InitSetup" Before="CostFinalize">UILevel=2</Custom>
</InstallExecuteSequence>

When upgrade is being executed, part of this action is to validate user password that is being provided in command line:

msiexec /i my.msi PROP_PASSWORD=12345

The PASSWORD property in is marked as Hidden and Secure:

<Property Id="PROP_PASSWORD" Hidden="yes" Secure="yes" />

During upgrade, while removing older version, InitSetup is triggered again but PROP_PASSWORD is not being passed to it so the action is failing and resulting overall upgrade fail.

Is there a way to force PROP_PASSWORD forwarding to the MSI that is being uninstalled?

eddyuk
  • 4,110
  • 5
  • 37
  • 65

2 Answers2

1

Conditioning: Is it really necessary to validate the license key on uninstall? Could you condition the custom action to not run on uninstall? It is possible to configure it to not run on major-upgrade initiated uninstall - as opposed to normal, manually triggered uninstalls. It involves the property UPGRADINGPRODUCTCODE. By adding NOT UPGRADINGPRODUCTCODE to your condition, the custom action will never run during major upgrades. Something like: UILevel=2 AND NOT UPGRADINGPRODUCTCODE. The condition NOT REMOVE="ALL" would prevent it from running on regular uninstall as well. Conditions are hard - there are many installation modes to test.

Persist Properties: You can also persist the password in the registry and construct your setup to read it back if it is there. This involves a registry search which WiX can easily do.

Live?: Are you live with your previous package? If so, you can patch the live version with a minor upgrade to change the installed product's uninstall sequence. In the above case I suggested to change the conditioning of the custom action, and this is possible with a minor upgrade.

Setup.exe Initiated Uninstall: If you use a setup.exe launcher made with Burn, one option would be to kick off the uninstall of your old version via the launcher, rather than from within the actual MSI itself (which has serious technical limitations due to the requirement for only one MSI installation session active at any time). This would allow you to pass any command line to the uninstall routine.

In my tired state that is all I can produce right now. I'll check back to see if you are live or not, and to see how much I have forgotten to mention.

Stein Åsmul
  • 39,960
  • 25
  • 91
  • 164
  • Thanks for response. I am live with original package. How would I patch it to change the uninstall sequence without triggering it in a first place? – eddyuk Sep 04 '18 at 07:19
  • [**That would require a minor upgrade**](https://stackoverflow.com/a/51444047/129130). It is an "in-place" upgrade of the installed product, rather than an uninstall of the old version and the install of the new version (which is what a major upgrade is). Please see that link for some more information. There are some challenges distributing the minor upgrade for future releases since you need it to be able to migrate older instances. I'll see if I can dig up some links on that (unless it is an "internal corporate package" where you have full control of the distribution system and apprach). – Stein Åsmul Sep 04 '18 at 07:22
0

Just to leave a closure on a subject on how I solved it eventually - or more accurately found a work around: Since the custom action had a condition UILevel=2 instead of initiating silent installation with /q instead I instructed to upgrade using /qb-. That will set UILevel to 3. From user experience point of view they will only see notification form and progress bar. It will not display blocking dialogs.

eddyuk
  • 4,110
  • 5
  • 37
  • 65