Wix Bundle部分升级后如何卸载未升级的相关安装包？

结论 #

既不需要自己手写代码调MSI卸载PackageB，也没必要放弃Bundle注册把单包直接扔ARP列表，这俩都是绕开Burn原生能力的非标准实现，后续维护坑很多。

正确实现步骤 #

• 你之前在旧Bundle嵌入式卸载流程里，监听PlanPackageBegin把PackageB的RequestState设为None阻止其被误卸的操作是没问题的，缺的只是新版Bundle对这个残留包的管辖注册步骤。
• 在新版BA的初始检测阶段，扫到属于旧Bundle安装的PackageB时，不要在PlanRelatedBundle事件里把对应旧Bundle实例的动作设为全量移除：判断如果这个包本身就在新版Bundle的包清单里、当前处于已安装状态、本次升级流程里没规划对它的升级/卸载动作，就直接把它的已安装状态同步到新版Bundle的本地包状态缓存里，注册成当前新版Bundle下的已安装可选包即可。
• 等后续用户从ARP触发新版Bundle的修改/卸载流程时，BA进入维护模式，正常在功能选择页放出两个包的勾选选项就行，用户要卸PackageB的时候，直接给这个包设RequestState.Absent，Burn会自动走原生MSI卸载流程，不用你自己额外写调用逻辑。

两种备选方案的问题 #

• 自己写代码直接调MSI卸包：Burn本身已经封装好了MSI事务回滚、共享组件引用计数、UAC提权、日志关联、错误码处理这些逻辑，自己重写一套很容易出卸载残留、安装状态不一致的问题，后续版本迭代还要兼容这套自定义逻辑，维护成本极高。
• 放弃Bundle注册把单包直接暴露到ARP：相当于直接丢了Burn的依赖统筹、升级链路管理能力，后续两个包如果有共享运行时、需要推联动补丁、做版本兼容校验，你得给每个MSI单独写逻辑，还容易出现用户卸一个包时误删共享组件，导致另一个包直接崩溃的问题。

只有一种情况可以考虑直接暴露单包到ARP：两个包完全独立，没有任何共享组件、未来也不会做任何联动的功能更新或依赖校验，否则一律走原生包注册逻辑。

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