如何卸载无升级机制的WiX包？v1升级v2卸载失败求助
首先，咱们先拆解一下你遇到的核心问题：原v1 bundle没有升级卸载逻辑，你试图通过覆盖C:\ProgramData\Package Cache里的旧bundle来修复卸载能力，但v2升级时依然无法完成v1的卸载，而v2到v3的升级正常——这说明问题出在原v1的缓存覆盖逻辑和v2升级逻辑的匹配上。
从日志里找关键线索
先看你提供的日志细节：
Detected related bundle: {297fb3b4-f677-4d92-a81a-c0448587b072}, type: Upgrade, scope: PerMachine, version: 1.1.0.0, operation: None
Detected related bundle: {90a15f11-66af-4682-8b09-7f3600f5bacf}, type: Upgrade, scope: PerMachine, version: 1.2.0.0, operation: None
Plan begin, 7 packages, action: Uninstall
Plan skipped removal of provider key: {78089b86-4712-4498-b4f6-7a4544d721b8} because it is registered to a different bundle: (null)
Plan skipped related bundle: {90a15f11-66af-4682-8b09-7f3600f5bacf}, type: Upgrade, because it was previously scheduled.
这里有两个关键问题：
- Provider Key关联失效：原v1里的某个包的provider key被标记为注册到
(null)，说明你覆盖的修改版bundle和系统中记录的原v1 bundle身份不匹配，导致WiX无法识别这个包属于要卸载的bundle，直接跳过了卸载。 - 修改版bundle被重复调度：你做的修改版v1（1.2.0.0）被检测为独立的bundle，和原v1（1.1.0.0）被同时识别，但升级计划里它被标记为“已调度”而跳过，等于没用到你修复的卸载逻辑。
针对性解决方案
方案1：让修改版v1完全匹配原v1的身份标识
WiX的bundle是通过Bundle ID和版本号来唯一识别的，你现在的修改版v1用了新的版本号（1.2.0.0）和新的Bundle ID，导致系统把它当成了一个全新的bundle，而不是原v1的修复版。你需要：
- 保持修改版v1的
Bundle Id和原v1完全一致（就是那个{297fb3b4-f677-4d92-a81a-c0448587b072}） - 保持版本号和原v1一致（1.1.0.0），只修改卸载逻辑部分
- 用这个完全匹配的修改版bundle覆盖
Package Cache里的原v1文件，确保权限足够（用管理员身份操作）
这样系统会认为缓存里的还是原v1 bundle，v2的升级逻辑调用它时，就能正常执行你添加的卸载逻辑了。
方案2：在v2里直接添加原v1的卸载逻辑，跳过缓存覆盖
如果你不想冒覆盖缓存的风险，可以在v2的引导程序里直接处理原v1的卸载：
- 在v2的Bootstrapper Application中添加自定义检测逻辑，判断原v1是否存在（通过Bundle ID查询注册表：
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{原v1 Bundle ID}） - 如果存在，直接调用WiX的卸载命令：
burn.exe -uninstall {原v1 Bundle ID} -quiet，等待卸载完成后再继续v2的安装流程 - 这种方式不需要修改原v1的缓存，直接通过系统注册信息触发卸载，更稳定
方案3：检查缓存覆盖的完整性和权限
如果你坚持用覆盖缓存的方式，需要确保：
- 用管理员权限运行覆盖操作，否则可能无法修改
ProgramData下的文件 - 覆盖的文件要和原v1的缓存文件完全对应，包括所有依赖的包和元数据，不能只替换主bundle文件
- 覆盖后手动测试修改版v1的卸载：运行
{修改版bundle路径} -uninstall -quiet，确认原v1能被正常卸载，再测试v2的升级
为什么v2到v3没问题？
因为v2本身已经具备完整的卸载逻辑，v3的升级逻辑可以直接通过正常的WiX升级流程识别v2，调用它自带的卸载逻辑，不需要依赖缓存覆盖，所以流程正常。
内容的提问来源于stack exchange，提问作者Mark U
