RTM基于WiX Toolset 3构建，迁移HF/SP至WiX5后注册表更新异常求指导

确实有不少人成功实现了这种跨WiX版本的热修复场景，以下是实际验证过的关键要点：

• 严格对齐Windows Installer核心规则
  WiX只是MSI的生成工具，最终执行逻辑由Windows Installer引擎决定。热修复必须完全遵循补丁规范：

  • 热修复MSI的ProductCode必须和RTM完全一致，ProductVersion要高于RTM，PackageCode必须唯一
  • 涉及注册表更新的Component，其ComponentId、Guid必须和RTM里的对应组件完全匹配，注册表项的路径、值名称、类型也不能有任何改动。如果RTM里该组件是共享组件，热修复里必须保持相同的共享配置

• 修正WiX 5的默认行为差异
  WiX 5相对于WiX 3有一些默认配置变更，容易导致注册表更新失败：

  • 注册表项的KeyPath：WiX 3默认会把注册表项设为组件的KeyPath，但WiX 5可能需要显式指定KeyPath="yes"在RegistryValue元素上，否则Windows Installer可能认为组件无需更新
  • 组件属性：如果RTM里的组件设置了NeverOverwrite或Permanent，热修复里必须原样保留，不然Installer会跳过组件更新
  • 注册表值类型：检查WiX 5生成的注册表值类型是否和RTM一致，比如别把REG_SZ默认改成了REG_EXPAND_SZ

• 用安装日志定位问题根源
  生成详细安装日志（命令：msiexec /i Hotfix.msi /l*v install.log），重点找这些内容：

  • 对应注册表组件的状态，看是否被标记为skipped，以及具体原因（比如版本不匹配、KeyPath未检测到变化）
  • 日志里的Registry相关操作记录，确认Installer是否尝试写入注册表，还是被规则拦截

• 规范补丁包构建流程
  如果用WiX的torch和pyro构建补丁包，注意：

  • WiX 5的torch和WiX 3生成的MSI兼容性没问题，但对比差异时要加-p参数处理补丁专属的差异逻辑
  • PatchCreation元素要正确配置TargetProductCode和VersionRange，确保补丁只针对RTM版本生效

• 验证组件状态变化
  安装RTM后，执行msiexec /i {你的ProductCode} /l*v status.log查看组件状态，确认注册表对应的组件是已安装状态。安装热修复后再查一次，确保该组件被成功更新

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