0

We changed the UpgradeCode component to a different GUID. Is there a way to change an installed product's UpgradeCode without redoing the install?

Stein Åsmul
  • 39,960
  • 25
  • 91
  • 164
CoderX
  • 11
  • 1

1 Answers1

1

Live?: Is the product live yet? If not, just uninstall all instances and revert to the original upgrade code? (Especially the case if you are in a corporate environment with proper control of deployment via a distribution system - then there are no constructs needed to add to the package itself for eternity).

Hotfix: Some would suggest hotfixing the cached installation database. I wouldn't even try. I find it very hacky, even when using the MSI API (Win32 functions / COM API to manipulate MSI files).

Upgrade Table: I haven't done so in ages, but you should be able to author the erronous upgrade code into your MSI file's Upgrade Table in addition to your main one. In other words, you can detect multiple related products (or even unrelated products), each with different upgrade codes by authoring the Upgrade Table. You would generally need to leave that legacy entry in there for the foreseeable future though, to ensure smooth upgrades for as long as that particular product line is relevant. You could keep using the new upgrade code, or revert to the old one (but you need both entries in there for as long as this product line updates - if you are live with all versions).

Sample: I am doing something along the lines of what is described above here: Adding entries to MSI UpgradeTable to remove related products

Stein Åsmul
  • 39,960
  • 25
  • 91
  • 164
  • I would also do it by adding a "legacy" entry to the upgrade table of the new version of the package. Hacking the cached package is a very bad idea. Windows Installer already has so many quirks even without applying such hacks. Please don't further complicate the situation. – zett42 Jun 29 '19 at 06:43
  • 1
    Agree, far too many hacks going on, and Windows Installer is high complexity. Don't fight the technology, if fights back. Bummer with the more complicated Upgrade-table though. It needs to remain in there and you have more to test. Can't escape [the complexity of deployment](https://stackoverflow.com/a/12101548/129130) (a bit down the page): once you go live, problems are cumulative - they accumulate (my fix for my failed fix failed, etc...). Unavoidable, just has to be managed I think (or you have to go side-by-side with your new version - that is a lot of work and testing too). – Stein Åsmul Jun 29 '19 at 11:15