As part of the update process which is working well for us, we would like to add an extra confirmation dialog so an end user can accept or
Disclaimer: The below procedure or sample is a demonstration only - it is not necessarily a recommendation. The functionality itself (abort major upgrade) and the use of VBScript (frowned upon by deployment pros) make this procedure undesirable, but possible.
I don't use VBScript in MSI files, they are generally not reliable, but for something as simple as this, I suppose they could be used. It would avoid creating any custom MSI dialogs and to mess with the dialog sequence (inserting your custom dialog into the setup GUI sequence) - instead you could just show a message box from the VBScript itself asking "yes" or "no" whether you want to continue or not.
Here is a quick mock-up (apologies for the lackluster code, just trying to show how it can be done in a quick way - a bit too rushed - this is just one way to do it):
On Error Resume Next
themessage = "Do you want to continue upgrading?"
messagetitle = "Continue to upgrade?"
messagetype = vbYesNo + vbInformation + vbDefaultButton1 + vbSystemModal
userresponse = MsgBox (themessage, messagetype, messagetitle)
' Abort if requested by user
If userresponse = vbYes Then
Session.Property("DOUPGRADE") = "YES"
Else
Session.Property("DOUPGRADE") = "NO"
End If
Then you add a type 19 custom action
to run directly after your VBScript custom action and it will terminate the install if DOUPGRADE is set to "NO". In other words you condition that type 19 custom action with DOUPGRADE ~= "NO"
and throw in NOT REMOVE="ALL"
. I suppose I could just return an error from the VBScript directly (we are running immediate, so there is no transaction rollback needed), but it seems better to use the built-in abort custom action method. I am not sure if the WScript.Quit(errnumber) feature works from VBScripts hosted by the msiexec engine itself. I didn't try it.
UPDATE: see here: how to terminate msi installation using vbscript custom action, and resurrected using WayBackMachine: Installshield Newsletter: Exiting an MSI Installation from a Custom Action (recommended).
You would need to insert the VBScript custom action after FindRelatedProducts
in the InstallUISequence
(user interface sequence). Just set it to run synchronously and immediate. Make darn well sure to only show it when YOURUPGRADEPROPERTY
is set! (this is the property set in the Upgrade table - ActionProperty column - to hold the list of related products found by FindRelatedProducts). Maybe add AND NOT PATCH AND NOT REMOVE~="ALL"
as well. Please test yourself.
It is late and conditions are always confusing and error prone and easy to mix up (when they are set etc...). Maybe have a look here: How to add a WiX custom action that happens only on uninstall (via MSI)? I can't guarantee that table - I haven't taken the time to test the information systematically, but it looks OK at face value. However, I believe REMOVE
can sometimes be set during installation for example - it is very complicated to deal with all permutations of possibilities since MSI's command line interface and property configuration is so flexible. At least it helps to plan testing. Finally, Installed
will be true in a minor upgrade, but not in a major upgrade (a major upgrade is a new product uninstalling an older product - the new product is not technically installed - yet). All of this summarized here: Is it possible to run a custom action only in repair mode.
There is another such condition cheat sheet from Installshield here - I have never tested the conditions. I repeat myself, but real life testing is crucial. As Grady Booch puts it: "...users are amazingly creative when it comes to exercising a system in unexpected ways" (src).
Now test a full cycle of your setup deployment. Install, repair, self-repair, uninstall, upgrades, patching (if any) to verify that unexpected side effects are not seen (you will always see some). Don't rely on my suggested conditions above - it is very late here :-). Test well.
Is this added risk for such a feature really worth it? Just asking. "Afterthought" features like these tend to create a lot of support calls - in my experience. Frankly I have never seen this feature in any setup I think - though it does make sense to ask.
Additionally: if you deliver your setup in many different languages you will need to localize this dialog and the abort message. I have some mock-up VBScript code for that as well if you do need localization.
Completely full instructions are not feasible because you need to create a dialog to insert when an upgrade is detected, and that needs hooking into the Next/Back sequencing. I'll also add that most people know that they are installing an upgrade of a product they have installed and don't need an extra prompt, so that's why this is uncommon.
In general you make the "do you want to upgrade" dialog with Next and Cancel buttons asking whether the upgrade should proceed. Condition showing this on WIX_UPGRADE_DETECTED. UPGRADINGPRODUCTCODE is not relevant because it is set in the older product that is being upgraded.
The WIX_UPGRADE_DETECTED property is the product code (or list) of the product(s) being upgraded, so you could think about querying the name and version of that product, but this typically doesn't work when the query requires elevation (because the UI sequence is not elevated).