如何在客户UI应用中实现升级？调用Engine.Plan(LanchAction.UpdateReplace)无效

1. 先确认Upgrade元素的核心配置 #

• 新旧版本的UpgradeCode必须完全一致，GUID的大小写、格式都不能有偏差，这是Wix识别同一款产品的唯一标识
• 新版本的ProductVersion必须严格高于旧版本，且必须符合四位数字的版本格式（如2.0.0.0，不能是2.0）
• 检查Upgrade元素的版本范围设置：MinimumVersion要覆盖旧版本号，MaximumVersion要设为新版本以下的区间（比如旧版是1.0.0.0，新版设MaximumVersion="1.9.9.9"），同时确保OnlyDetect属性为no（默认值，但最好显式声明）

2. 验证Bootstrapper的Plan动作逻辑 #

• 注意拼写：是LaunchAction.UpdateReplace而非LanchAction.UpdateReplace，参数拼写错误会直接导致动作不生效
• 确认调用Engine.Plan()的时机：必须在DetectRelatedProducts完成之后，也就是Bootstrapper已经检测到旧版本存在时再执行该动作
• 如果是自定义Bootstrapper Application（BA），要确保检测到旧版后，正确触发UpdateReplace动作，而不是默认的Install流程

3. 排查新版本安装包的构建问题 #

• 新版本MSI的ProductCode必须和旧版不同（同一UpgradeCode下，不同版本必须使用不同的ProductCode），但UpgradeCode要保持一致
• 用Orca工具打开新版本MSI，查看UpgradeTable，确认Upgrade元素的配置已经正确嵌入到安装包中
• 确保新版本的所有文件版本都高于旧版，Wix默认会跳过版本号相同或更低的文件替换，导致UI应用未更新

4. 检查运行时权限与日志 #

• 必须以管理员权限运行bootstrapper.exe，更新操作需要写入受保护目录（如Program Files），无权限会静默失败，不会弹出错误提示
• 查看Windows应用程序事件日志，筛选MSI安装相关的错误事件，根据错误码（如1603、1638）定位具体问题，比如文件锁定、依赖缺失等

5. 兜底验证步骤 #

• 手动卸载旧版本后，直接安装新版本，确认新版本本身可以正常安装，排除安装包自身的问题
• 检查旧版本是否有未卸载干净的组件，比如遗留的注册表项、文件，导致新版本无法覆盖替换

内容的提问来源于stack exchange，提问作者henxun xun