这就是我们现在所拥有的：
<InstallExecuteSequence> <ScheduleReboot After="InstallFinalize"/> </InstallExecuteSequence>
提前谢谢了！
您需要按照此处描述的内容为您的ScheduleReboot条目插入条件：https://www.firegiant.com/wix/tutorial/events-and-actions/extra-actions/(链接的文章可能会显示有些过于包容或不受限制的条件).
更新：有一些问题需要考虑：
>不需要的操作：除非确实有必要,否则不应使用ScheduleReboot.例如,如果您尝试替换正在使用的文件,MSI将在不调用ScheduleReboot的情况下处理该文件.
>许多安装模式：没有适当的条件,ScheduleReboot将导致重启提示出现在许多安装模式：安装,卸载,升级,修复,自修复,修补等……这是不可取的.
>无提示,即时重启：如果MSI以静默方式运行且未指定REBOOT = ReallySuppress,则ScheduleReboot操作将自动触发相关计算机的即时重启 – 这可能非常令人惊讶且非常不受欢迎.
出于您的目的,您可以使用以下条件：
<InstallExecuteSequence>
<ScheduleReboot After='InstallFinalize'>NOT Installed AND NOT WIX_UPGRADE_DETECTED</ScheduleReboot>
</InstallExecuteSequence>
这完全取决于您是要在主要升级期间安排重新启动,还是仅在原始的全新安装期间安排？没有更多信息就没有办法告诉你.一个更普遍的条件,如未安装和不删除〜=“全部”似乎计划在重大升级期间重新启动,但不是手动卸载不是由主要升级触发(我会测试我什么时候获得机会 – 更新：经过验证,仅限基本测试).
请注意,特殊的WIX_UPGRADE_DETECTED属性是WiX-specific construct,只有在使用WiX的MajorUpgrade元素时才可以设置该属性.您还可以使用set up major upgrades the old fashioned way in WiX并避免使用MajorUpgrade元素“便利功能”,这样可以使用更少的选项轻松配置主要升级 – “自动魔术”.我没有验证是否仍使用此“旧学校”主要升级配置设置了WIX_UPGRADE_DETECTED.
您还可以使用Upgrade table中的ActionProperty来检测主要升级是“即将发生”(see this answer for a sample).这应该适用于非WiX MSI设置 – 因此应该是WIX_UPGRADE_DETECTED的替代(我相信在FindRelatedProducts运行之后设置此属性).
WIX_UPGRADE_DETECTED与UPGRADINGPRODUCTCODE
在主要升级期间卸载的MSI软件包将设置特殊属性UPGRADINGPRODUCTCODE(在升级期间不会在安装的MSI中设置).这是一个内置的MSI属性,而不是特定于WiX的构造.换句话说,在主要升级期间 – 卸载旧版本和安装新版本 – 卸载的MSI将设置属性UPGRADINGPRODUCTCODE,而安装的MSI将设置属性WIX_UPGRADE_DETECTED(我将验证这很快).在标准操作FindRelatedProducts运行后,它还将具有来自Upgrade表集的ActionProperty.
如果这听起来很复杂,那我恐怕就是这样.这是Windows Installer(despite the technology’s major corporate benefits)的一个关键问题 –
基本的关键操作 – 例如升级 – 有时非常复杂.可能存在一些违反the principle of least astonishment的行为.显然,所有技术都有好坏之处.
特别注意事项
请注意,无论ScheduleReboot action是否被禁止,都可以启动重启(例如,如果有文件无法替换 – 或者更糟：自定义操作强制通过代码重启 – 这总是错误的,重启应该是预定不通过代码强制).
您可以使用REBOOT property(您已经阅读过的内容)禁止某些重启系统的提示. More on System Reboots.
MSI条件
为了做到正确,MSI条件可能非常棘手.搞错了,你的行为在错误的安装模式下意外运行 – 或者根本不应该运行.这比你想象的更容易出错 – 即使有经验.证明就在这里的布丁,现实生活中的测试.以下是一些示例,复杂条件的示例：Wix Tools update uses old custom actions(以防万一有趣).
当您尝试使用复杂条件(或任何条件)时,您应该测试许多安装模式：1.全新安装,2.修复,3.修改,4.自修复,5.修补,6.卸载,7.主要升级调用卸载等…还有一些奇怪的模式,如恢复暂停安装以@L_403_12@为特色,以及AFTERREBOOT property与ForceReboot action相关等等……应该记住的事情很少被测试.
这里有两个用于调节的“作弊表”：
> Installshield condition cheat sheet
> How to add a WiX custom action that happens only on uninstall (via MSI)?
我没有时间经历所有这些条件并对它们进行测试,但后一个表看起来很合理.但是：我相信REMOVE有时可以在安装期间(以及更改期间)设置.处理所有可能的排列非常复杂,因为MSI的命令行界面和属性配置非常灵活.对于作为主要升级的一部分安装的新MSI版本,也没有设置已安装,但是将为卸载的MSI版本设置安装 – 非常令人困惑.
Installshield备忘单我从未主动使用或检查,但我发现他们的修复建议至少可以说 – 根据修复的调用方式,有不同的条目.
请记住还要检查自我修复 – 只需删除主应用程序EXE并通过调用应用程序的广告快捷方式(如果有)来触发自我修复.我检查了多年,但自我修复只能在InstallInitialize和InstallFinalize之间运行.您不希望在自我修复期间安排重新启动.
