Windows Installer升级场景下ComponentID变更是否影响组件更新？

结论 #

执行从Product1到Product2的minor upgrade（小型升级）时，Component1不会按预期完成版本更新，最终会出现组件状态异常，不会稳定升级到2.0.0.0版本。

核心规则依据 #

Windows Installer（MSI）的组件身份识别逻辑完全以Component GUID为唯一标识，和组件携带的文件版本、文件名、安装路径没有绑定关系，小型升级的增量更新逻辑有两个关键约束：

• 小型升级不会变更原有产品的ProductCode，所有更新操作都基于已安装产品的组件、功能映射关系做增量处理
• 只有升级包中GUID和已安装组件完全匹配的条目，才会触发版本对比、覆盖更新逻辑

实际运行表现 #

当新版本修改了Component1的GUID后，升级过程会出现以下行为：

• 原有1.0.0.0版本的旧组件，因为GUID没有出现在升级包的组件列表中，不会被标记为待更新、待卸载项，其注册表引用、安装路径记录都会被保留
• 新的2.0.0.0版本组件会被识别为和旧组件完全无关的全新组件，执行独立的安装逻辑：如果新旧组件的安装路径、文件名完全一致，会触发Windows Installer的文件版本判定规则，当磁盘上现有1.0.0.0文件版本低于2.0.0.0时，文件会被临时覆盖为新版本，但两个组件的引用计数会完全混乱
• 后续执行产品修复、补丁更新、卸载操作时，会因为组件引用关系错乱，出现功能缺失、文件被误删除、残留无效注册表项等问题，无法得到稳定的2.0.0.0版本组件运行状态

注意事项 #

同一安装路径下的同一文件，只要属于同一产品线的迭代版本，绝对不能随意修改Component GUID，这是MSI组件设计的核心规则。如果要修改组件GUID，必须通过变更ProductCode的重大升级（major upgrade）流程，且正确配置RemoveExistingProducts的调度顺序，先完全卸载旧版本再安装新版本，才能规避状态异常问题。

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