Wix Burn安装程序无提示安装时无重启

Question

I have a wix bundle which installs various modules. One of the modules amongst those can cause the system reboot. Now the way I would like to happen is that if it is a UI installation then at the end of the installation of the bundle I would like for a prompt to appear and if it is a silent install then I would like to avoid automatic reboot since the user might not be aware that the installation would cause reboot.

I looked at various threads and options and found that I can pass a "/norestart" parameter for silent install and that would take care of not doing the automatic reboot. So I want to fail the silent install if the user doesn't pass the "/norestart" parameter and allow only if that parameter is passed. I was hoping that the "/norestart" would map to a particular value of the REBOOT ( https://msdn.microsoft.com/en-us/library/windows/desktop/aa371101(v=vs.85).aspx ) but what I am observing is that irrespective whether I pass the "/norestart" parameter or not, the value of REBOOT in the logs is always "ReallySuppress" but it does not automatically reboot when the parameter is passed and reboots when the parameter is not passed. I am really confused as to how it is determining that and how I should programmatically determine it.

This is from the logs of one of the components when it reboots (when I don't pass the "/norestart" parameter)

Command Line: ALLUSERS=1 ARPSYSTEMCOMPONENT=1 MSIFASTINSTALL=7 CWD=<...> REBOOT=ReallySuppress CURRENTDIRECTORY=<...> CLIENTUILEVEL=3 MSICLIENTUSESEXTERNALUI=1 CLIENTPROCESSID=2240

This is from when it doesn't reboot (when I pass the "/norestart" parameter)

Command Line: ALLUSERS=1 ARPSYSTEMCOMPONENT=1 MSIFASTINSTALL=7 CWD=<...> REBOOT=ReallySuppress CURRENTDIRECTORY=<...> CLIENTUILEVEL=3 MSICLIENTUSESEXTERNALUI=1 CLIENTPROCESSID=1984

Any help or pointers is appreciated. If you want me to give more info or if something is unclear then let me know. Thanks in advance for your time.

Ref: https://msdn.microsoft.com/en-us/library/windows/desktop/aa372024(v=vs.85).aspx

https://msdn.microsoft.com/en-us/library/windows/desktop/aa371101(v=vs.85).aspx

Answer 1

As you have found, MSI packages are always suppressed from initiating a reboot.

What you are missing is that the Bootstrapper Application (eg WixStdBA or a custom / Managed BA) is what controls reboots.

The BA inspects the result of the installation of each MSI package. If any of the MSI packages require a reboot, the Bootstrapper Application will initiate the reboot (or not, if the user disallows it or the /norestart switch was passed etc).

The /norestart command line switch only prevents the Bootstrapper Application from initiating a reboot at the end of the bundle / chain.

I'm pretty sure you'd have to use a custom Bootstrapper Application if you wanted to block installation based on the absence of /norestart .

But if you're going to use a custom Bootstrapper Application, you might as well just change the default behaviour (ie make /norestart the default).

Answer 2

The default value for the REBOOT property is not ReallySuppress, so something else is going on. Without looking at the source, any custom actions, or the MSI it's hard to say why this is. A complete verbose log might show it being set; it might be in the Property table of the MSI; it could be set from custom action code; What else is on the command line? It needs some detective work.

The other issue is that a completely silent install is not going to ask for a reboot, because silent means that it cannot ask, so it's somewhat unclear what the settings are for other properties, ScheduleReboot possibilities and so on. I find it easier to use the traditional command line options, such as /qb and so on because they tend to be more explicit about what they do. Post a complete full verbose log somewhere if you need people to decipher it.

Suppressing reboots typically isn't a good idea. The main reason they are required is that files need replacing in a way that requires a reboot. That means that the install is incomplete until the next reboot, and attempting to run the installed app can cause issues if it uses the older files instead of the newer ones that are not yet in place.