使用MSI执行Minor Upgrade后版本升级成功但文件未替换，求排查建议

这种情况我之前帮同事排查过好几次，大概率是MSI的配置或者升级逻辑踩坑了，给你列几个最常见的排查方向：

• 文件版本没跟上
  MSI的小升级逻辑很“死板”——只会替换版本号明确更高的文件。如果你的新版本文件版本号和旧版一致，甚至不小心搞低了，MSI直接就跳过替换了。一定要确认：

  • 升级包里的文件FileVersion确实比已安装的旧文件高
  • 别只看安装包的产品版本，要去看单个文件的属性，有些编译工具可能没同步更新文件版本

• MSI升级包的类型配置错了
  小升级有严格的规则：

  • 升级包的ProductCode必须和原安装包完全一致，ProductVersion只能改第三位（比如从1.0.0更到1.0.1）
  • 要是不小心做成了小更新（Small Update）或者大升级（Major Upgrade），就容易出问题。可以用Orca工具打开MSI，查Product表的版本和Upgrade表的配置，确认是不是标准的小升级包

• 直接运行MSI缺了关键参数
  双击MSI默认的执行逻辑可能不够“强硬”，试试用命令行跑：

  msiexec.exe /i "你的升级包路径.msi" REINSTALL=ALL REINSTALLMODE=amus
  

  REINSTALLMODE=amus是强制MSI重新安装所有组件并替换符合版本条件的文件，默认模式可能会跳过一些非关键文件的替换

• 组件的KeyPath配置有问题
  每个文件对应的Component表如果把KeyPath设成了注册表项或者其他资源，而不是文件本身的话，只要KeyPath没变化，MSI就会觉得这个组件不需要更新，自然不会替换文件。另外还要确认组件的ComponentId和原安装包完全一致，小升级里组件ID不能改

• Setup.exe帮你做了额外工作
  Setup.exe作为引导程序，会处理很多MSI本身不会管的事：

  • 自动检测并关闭正在占用目标文件的进程（要是文件被占用，MSI可能静默跳过替换，但setup.exe会提示你关程序）
  • 自动添加正确的升级参数，或者提前处理一些依赖项（比如.NET运行库更新），这些都能间接保证文件替换成功

建议先从检查文件版本和命令行参数开始试，这俩是最容易踩的坑。如果还是不行，用Orca把原安装包和升级包的File、Component、Upgrade表对比一下，肯定能找到配置差异。

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