Wix - Deferred Custom Action fails on Upgrade, resulting in the product being completely removed

Question

The Setup

So I have a Custom Action that is marked as Deferred and executes Before InstallFinalize. It looks like this:

  <CustomAction Id="CADeferred"
                BinaryKey="binaryCustomActions"
                DllEntry="CADeferredMethod"
                Execute="deferred"/>

  <InstallExecuteSequence>
  ...
  <Custom Action="CADeferred"
          Before='InstallFinalize'>Not Installed or Upgrading</Custom>
  </InstallExecuteSequence>

And I have Version 1.0 installed currently on the computer environment & fully functional. I then use the Version 2.0 MSI to do an Upgrade.

The Issue I'm Running Into

When doing the Upgrade, that Custom Action can fail and returns ActionResult.Failure. When that happens, the installer fails and says:

"Product Setup Wizard ended prematurely because of an error. Your system has not been modified. To install this program at a later time, run Setup Wizard again. Click the Finish button to exit the Setup Wizard."

Once I click Finish. I checked that the product itself has been removed completely from the computer environment. Like it has been uninstalled essentially.

I was hoping it would Rollback to the Version 1.0 as it was before the Upgrade.

What I'm Trying To Accomplish

If this scenario happens, I like the installer to Rollback to Version 1.0 on the environment.

What I've Done So Far

I've researched on Google for more information on how InstallFinalize works, how Rollbacks work, etc.

From my research, having a Deferred Custom Action to run Before InstallFinalize is the way to go for a Custom Action that needs to modify state on the environment. As well as being able to use the new files on the new installer such as a DLL because it runs "inside" the InstallFinalize step. Since it's defined Before InstallFinalize I thought the Rollback of it would put the system back to the previous installed version of the product.

I've tried making it into a Immediate Custom Action to run After InstallFinalize, but that's bad. If it fails, the product still Upgraded to Version 2.0. Which is odd. Plus I know this is frown upon. So I went to Deferred Custom Action to run Before InstallFinalize.

I also read that usually Deferred Custom Actions have a Rollback Custom Action associated with it. However, due the functionality of the Deferred Custom Action, we can't necessarily fix the issue with a Rollback Custom Action. Reason is because it takes an admin to really check out the failure and manually do any changes needed for a retry of the Upgrade to work the next time. So hence we don't include an associate Rollback Custom Action.

So I'm pretty stumped at this point. Any help or direction would be very much appreciated. If I'm not being clear enough, feel free to ask for more clarification. Please and thank you.

Stein Åsmul Stein Åsmul · Accepted Answer · 2018-08-27T17:20:42

Please read the following MSI SDK description: RemoveExistingProducts Action. Essentially the placement of the standard action RemoveExistingProducts will affect how rollback works, and in effect if it works at all. This standard action runs the uninstall of the old setup during a major upgrade - which under the hood is not really an upgrade, but an uninstall of the old product and an install of the new product - with several different "flavors" of sequencing - in other words what happens first, the uninstall or the install.

Late RemoveExistingProducts sequencing allows proper rollback (details in the SDK article linked to above). For late placement of RemoveExistingProducts to work correctly, you have to be careful that the component rules are not violated, or files will be missing after the update if you sequence the uninstall late. This is because in this scenario the new version installs as a patch. It patches the changed files and then removes whatever is obsolete. In the early uninstall scenario you "de-couple" yourself from these reference count issues - the old product is completely gone before the new one is installed - and hence you can't roll back to it (unless you manually reinstall it). In other words: early RemoveExistingProducts it is more forgiving of setup design mistakes - and hence more used in the real world.

The configuration of the major upgrade is determined by either the MajorUpgrade element or Upgrade Elements.

Some Links:

Wix - Deferred Custom Action fails on Upgrade, resulting in the product being completely removed

1 Answers