I have created a bundle using WIX.
Use /forcerestart
instead. It's the Standard Installer Command-Line Options that Burn follows.
Burn Reboot Notification: As far as I know Burn will show a reboot prompt after installation if any of the embedded MSI files schedule a reboot (that can be done by scheduling the standard actions ScheduleReboot
or ForceReboot
- and Windows Installer will schedule a reboot by itself if a file can not be replaced during installation).
I believe the Burn bundle will handle suppressing the reboot until the installation is done - by virtue of the command line they use to invoke each MSI, but I am not 100% sure. There could be special concerns for ForceReboot. Just use ScheduleReboot, and condition it well - as explained here.
Moreover the whole bundle seems to refuse to uninstall if a reboot is pending. Not sure what happens when the bundle runs in silent mode, it seemed to kick off a failed reboot. Haven't tested too thoroughly.
Pending some testing. Need to do something else first.
Rant: I wrote a whole reboot-rant, just for you below :-). The gist of it: just do not reboot unexpectedly or spontaneously.
Unfortunately Windows Installer itself will spontaneously reboot when run in silent mode, unless you specify
REBOOT=ReallySuppress
on the command line - if a reboot is indeed pending.
Don't: Causing a spontaneous, unannounced reboot is actually technically easy (custom action, or an MSI run in silent mode that sets ForceReboot
- or even ScheduleReboot
without setting REBOOT=ReallySuppress
on the command line - described here - in detail - or you can hard-code the REBOOT property
to "Force"
in the property table - this will also trigger a reboot without warning). Rebooting like this is logically and pragmatically unsound. Extremely so in fact.
Ethics for Rebooting: Rebooting a knowledge worker's PC is very serious, I have seen people sent out the door for less. This is nothing to be nonchalant about: Dozens of Visual Studio windows, heaps of half-written emails, notes in notepad, and the plague itself: missed chat messages
and web pages without state management
, etc... Beyond losing data (which still happens, though most apps save before closing), people lose context (obvious, but still) - it is as if someone took your physical desktop and swiped it clean with documents ending up on the floor and in the trash can (now politically correctly referred to as the "recycle bin").
There is more:
"semi-automatic installation"
. In other words they kick of the batch file - it runs the MSI in silent mode with a few prepared settings and the box reboots without warning. Not sure what features have appeared in Windows to deal with this on server OSs.The bottom line is this: your software could be thrown out of whole companies for "behavior" such as this. Haphazard rebooting. It really can. As in "...if they do this, what else do they do that we can't live with".
Civilized Reboot: I am not sure of all the aspects here, but I would recommended something like this for software that can not work without a reboot:
msiexec.exe
- Windows Installer engine - you can suppress all reboots scheduled by an MSI, theoretically - there are still hacks).
removing system privileges for reboot to control what is going on
). I don't recommend they do this since this can cause other, unexpected problems - technical hacks always do. Always side-effects. The right approach is to eliminate reboot hacking in packages. Isn't it? Or an update to Windows that really suppresses unexpected stuff like this.I wish we could hide shortcuts added until reboot is complete
(if reboot is really, really needed). Or a modal dialog that can't be dismissed without kicking off reboot? Loaded gun that. I prefer to not add any buttons to kick off a reboot in the application, I just state a reboot is needed and exit - if this is indeed necessary. Less to test for the QA guys?