Wix 4 Custom BA - Upgrade does not complete uninstall of previous version

[kerrywicks]

This is likely to be something I'm doing wrong. I'm most of the way there with completing a conversion from Wix 3.11 to Wix 4.0.1, and this is the last part that has me stumped. I've trawled through the code base to try and find some code snippets around this, and I'm just not finding anything that deals with major/minor upgrades. I would appreciate any guidance I can get!

This used to work without issue in Wix 3.11. When requesting an upgrade previously, my package/msi would be flagged as upgrade, then the custom BA would hand the details over to a silent/non-UI process. This would then go into a bit of code that looked like this in the DetectComplete event of the engine:

if (LaunchAction.Uninstall == Bootstrapper.Command.Action)
{
   m_engine.Log(LogLevel.Verbose, "Invoking automatic plan for uninstall");
   m_engine.Plan(LaunchAction.Uninstall);
}

I'm obviously missing something here, as this no longer seems to work - I now have a message in my log that states 'Bootstrapper application already requested to quit, ignoring request: 'Plan'.', As a result, the uninstall part never happens (and no plan execute happens after this point like it used to), and I am left with duplicate bundles in ARP.

I've attached the upgrade log - is anyone else able to assist/point me in the right direction for making upgrades work with a custom BA in Wix 4?

Designer_100_20230707201936.log

Thanks!

[barnson]

What is your BA doing when logging this message?

[1DC0:9968][2023-07-07T20:19:37]i000: Quitting.

[kerrywicks]

That's a custom message I added due to debugging - it's fired off just before Engine.Quit(Result) is called in the Run method. That particular Engine.Quit seems be happening in the same place as it used to in the 3.11 version, so I think that used to be expected behaviour - I've attached an event log of a successful upgrade from the 3.11 version for comparison purposes.

I'll share the run method here, just incase something has changed with how the dispatcher operates. I have a separate viewmodel for silent running. In this case, the installer is run using a UIinstaller class, which fires off the upgrade/uninstall via the InstallerSilent. They both inherit from the same class.

protected override void Run()
      {
         Engine.Log(LogLevel.Verbose, "Entry point of WiX CustomBootstrapper");
         using var container = Container.SetupContainer(this);
         
         try
         {
            if (Command.Display == Display.Passive || Command.Display == Display.Full)
            {
               // Create main window with associated view model
               m_installerUiWindow = container.GetExportedValue<Window>("InstallerUI");
               m_installerUiWindowHandle = new WindowInteropHelper(m_installerUiWindow).EnsureHandle();

               Engine.Detect();

               m_installerUiWindow?.Show();

               Dispatcher.Run();
            }
            else
            {
               // silent installation - use the silent implementation of InstallerBase.
               Engine.Log(LogLevel.Verbose, "Executing silently.");
               var installerSilent = new InstallerSilent(Dispatcher.CurrentDispatcher);

               Engine.Detect();

               if (!installerSilent.IsUpgradeUninstallation())
               {
                  Dispatcher.Run(); // don't call run if we're doing an upgrade installation, as this will lose the dispatcher for the parent installation
               }
            }
         }
         catch (Exception e)
         {
            Engine.Log(LogLevel.Verbose, e.Message);
            Engine.Log(LogLevel.Verbose, e.StackTrace);

            if (e is CompositionException c)
               Engine.Log(LogLevel.Verbose, string.Join(" ", c.Errors.Select(o => o.Exception?.Message)));
         }

         Engine.Log(LogLevel.Verbose, "Quitting.");
         Engine.Quit(Result);
      }

Designer_100_4920_Upgrade_4919_Uninstall.log

[barnson]

I can't speak to the managed BA part but from the engine perspective, once the BA calls Quit, it can't call any other engine method (afaict).

[barnson]

https://wixtoolset.org/docs/fourthree/faqs/#active-engine-changes

[kerrywicks]

Thanks for taking the time to look into this for me! I did look at that bit of documentation - I was under the impression that SetUpdate was used for something else, and wasn't anything to do with Minor/Major upgrades.

I did start going down the path of looking into some examples that use that, but I wasn't quite able to get where the events DetectUpdate, DetectUpdateBegin and DetectUpdateComplete fall in the usual sequence of things (and they don't seem to get called without something specific!).

After reading your comments, I went back to looking at the code examples that use UpdateReplace as a launch action - however, the DetectUpdate events never fire off, so I can't call SetUpdate with a package source location. This leaves me with the following in the log when I attempt to Plan with UpdateReplace as the launch action:

[5F68:36AC][2023-07-08T16:43:41]i200: Plan begin, 5 packages, action: UpdateReplace
[5F68:36AC][2023-07-08T16:43:41]e000: Error 0x80070057: Invalid action state.
[5F68:36AC][2023-07-08T16:43:41]e000: Error 0x80070057: Failed to get default request state for action.
[5F68:36AC][2023-07-08T16:43:41]e000: Error 0x80070057: Failed to set default package state.
[5F68:36AC][2023-07-08T16:43:41]e000: Error 0x80070057: Failed to initialize package.
[5F68:36AC][2023-07-08T16:43:41]e000: Error 0x80070057: Failed to process update package.
[5F68:36AC][2023-07-08T16:43:41]e000: Error 0x80070057: Failed to plan update.
[5F68:36AC][2023-07-08T16:43:41]i000: EVENT: PlanComplete ({"Status":-2147024809,"HResult":0})

Is there something else I need to set to make the DetectUpdate events fire off? Where should they be in the sequence of events?

[barnson]

Update in those callbacks is talking about bundle updates downloaded via an update feed (Bundle/Update/@location). Upgrades are just installs (followed by the uninstall of the older bundle, if present). The change in behavior in WiX v4 is that Quit is now terminal.

[kerrywicks]

Thank you so much for your help on this - I finally cracked the problem after drinking more coffee, engaging my brain, and going through what you said a few times.

The problem was an erroneous Engine.Quit being called due to me not calling Dispatcher.Run() on the current dispatcher when running an upgrade - this got things into a state where Engine.Quit was called, then things were started up again but unable to proceed.

Back when using Wix 3.11, I think that the dispatcher got reused when running an upgrade, so calling Dispatcher.Run() caused issues. It was a long time ago when I put that bit of code together though, so I could be remembering incorrectly. Removing this clause:

if (!installerSilent.IsUpgradeUninstallation())
               {
                  Dispatcher.Run(); // don't call run if we're doing an upgrade installation, as this will lose the dispatcher for the parent installation
               }

and just calling Dispatcher.Run() has my upgrades running as expected once again.