explained

Upgrade vs repair vs reinstall: the MSI trio nobody reads the docs for

The three ways an installer can touch an existing installation, the RemoveExistingProducts timing trap, and why file-version overwrites behave the way they do.

ProofTune Project··5 min read
Explained illustration Explained

The three operations, exact

Repair
re-lays missing/corrupt components using cached source; does not change versions, does not re-run your tweaks
Upgrade (major)
new package+product codes, stable UpgradeCode; RemoveExistingProducts unwinds old product — file-overwrite rules decide what's replaced
Fresh install
clean slate; old product was removed first, so no costing logic applies

The two installer gotchas worth memorizing

  • Equal file version = not overwritten. MSI's costing engine compares FileVersion; same versions skip replacement even if bytes differ. Teams that forget to bump FileVersion ship no-op upgrades and wonder why bugs “still repro.”
  • Dual mode by feature flags. Default REINSTALLMODE=omus presumes versioned-file delta; installers that force v (rewrite from cache) can resurrect buggy cached copies on genuinely-fresh artifacts.

Evidence pattern: the preview pipeline stamps every build with distinct FileVersion precisely so upgrades land — the Win32 versioning principle the installer respects is the versioning principle the build discipline preserves.

ProofTune ProjectEngineering notes — every claim here names the bytes a real tool touches. Verify first, install second.
ProofTune logo

See these exact settings inside the real tool

The browser replica runs the same strings and states as the installed app — click around before you ever install anything.