3

I am creating a managed bootstrapper application with WiX Burn. I need to handle some ExePackage elements which may require a forced restart. This question has some tantalizing clues about how to handle the restart, but I'm having trouble getting it working.

I have <ExitCode Value="3010" Behavior="forceReboot" /> in the ExePackage elements, and I can see that triggering in the logs. I am listening to the Shutdown event that is raised by the BootstrapperApplication and setting e.Result = Result.Restart, though I haven't figured out how to capture the condition for when this should occur when the force reboot is detected in the Apply phase. I am testing if (Command.Resume == ResumeType.Reboot) in the Run method of my BootstrapperApplication going straight to the progress bar portion of my custom UI, but I'm not sure how to resume the Apply phase where it left off. Do I need to call Engine.Detect() or Engine.Apply in this case? Is there some special action I need to take to persist and restore the state to survive the reboot, or does the Burn engine handle all of that internally?

If anyone could point me to a working example of a WiX Burn managed bootstrapper application that handles reboots, I would appreciate it.

Community
  • 1
  • 1
Dan Jagnow
  • 1,175
  • 12
  • 28

1 Answers1

3

Check out the implementation of WixStandardBA, even though it's not managed. Basically it does the following:

  1. At startup, check the WixBundleForcedRestartPackage variable and store it in m_sczAfterForcedRestartPackage.

  2. Call Detect like normal.

  3. Call Plan like normal.

  4. In OnPlanPackageBegin, skip packages until the package that caused the restart.

  5. Call Apply like normal.

Burn takes care of persisting the variables across the restart.

Dan Jagnow
  • 1,175
  • 12
  • 28
Sean Hall
  • 7,629
  • 2
  • 29
  • 44
  • Thanks, Sean. I think your answer has brought me very close, but it looks to me like Burn is not persisting variables across the restart. I have several variables declared like this: ``. I can see these getting set to "yes" when the user opts to install that product in the managed bootstrapper UI, but then it gets reinitialized to an empty string after the reboot. Do I need to do something in my managed bootstrapper code to trigger the save or restore of the variable state? – Dan Jagnow Oct 14 '14 at 15:10
  • Ah, I had code that was setting the variables to 'yes' if the product was detected and 'no' if not. This was overriding the restored state. It is curious that the Burn logs show the variable being initialized to an empty string after the restart but never show the persisted value being restored - unless you specifically output the value to the log later. But in any case, it is working now. Thanks! – Dan Jagnow Oct 14 '14 at 15:39