0

Building MSIs with WixSharp since years, I always followed this rule which basically says:

For each new release of your application, change the ProductCode but never change the UpgradeCode.

This always worked perfectly but recently I discovered that installing a newer release of my application does not replace the previous version but instead is getting installed in parallel.

Running this PowerShell script gives me this result on a test machine:

enter image description here

My question

What is the reason that a MSI file does not replace an existing one upon installation with the same UpgradeCode?

(I've also posted this as a question on the WixSharp GitHub repository)

Update/solution

I've finally managed to solve it. Basically I did the following things:

  1. Removed the version string from my setups name (since MSI seems to also compare then names to check whether an upgrade is possible; only the same name seems to fit)
  2. Changed my version number from 4 to 3 digits, as Christopher pointed out. I.e. I'm now incrementing e.g. "1.0.0" to "1.0.1" etc.
  3. Added this code to my WixSharp ManagedProject instance:
    InstallScope = InstallScope.perMachine,
    MajorUpgradeStrategy = new MajorUpgradeStrategy
    {
        UpgradeVersions = VersionRange.OlderThanThis,
        PreventDowngradingVersions = VersionRange.NewerThanThis,
        NewerProductInstalledErrorMessage = "Newer version already installed.",
        RemoveExistingProductAfter = Step.InstallInitialize
    },
    

After these changes, an upgrade succeeded.

Uwe Keim
  • 39,551
  • 56
  • 175
  • 291
  • 1
    Check for upgrade table if there is any constraint with min and max version. Also, it would be worth to check msi verbose logging once. – Vivek Jaiswal Nov 29 '22 at 06:18
  • Thanks, @VivekJaiswal, being no MSI expert, I used Orca to inspect my MSI file. To my surprise there is no Upgrade table ([see screenshot](https://i.imgur.com/HjT7lfP.png)). Am I doing this wrong? I'll now take a look at verbose MSI logging when installing the MSI. – Uwe Keim Nov 29 '22 at 09:06
  • 1
    Strange. How Powershell is fetching upgrade code then? Can you check any previous version of msi for Upgrade Table. Upgrade Code resides in this table. – Vivek Jaiswal Nov 29 '22 at 12:15
  • 1
    UpgradeCode is fetched from property table. But Upgrade table should be there in order for major upgrade to work. https://learn.microsoft.com/en-us/windows/win32/msi/upgrade-table – Vivek Jaiswal Nov 30 '22 at 05:15

1 Answers1

3

The constraint is ProductCode not UpgradeCode. Only 1 MSI per ProductCode can be installed. Attempting to do so again will be a maintenance operation, small update or minor update.

Many MSI can share an UpgradeCode. (Not a good practice though!) For example it's not required for you to author a Major Upgrade at all.

The usual cause here though is you must change the version number in the first three fields and each install must be in the same context (per-user and per-user or per-machine and per-machine). BTW that's another way to install the same ProductCode twice. One per-user and one per-machine. Again not a good practice.

Good:

1.0.0 → 1.0.1 FindRelated Products in the 1.0.1 MSI will see the 1.0.0 and tell RemoveExistingProducts to remove it.

1.0.0 → 1.0.0 or 1.0.0.0 → 1.0.0.1 Bad. FindRelated will see it as the same version and not remove it.

Uwe Keim
  • 39,551
  • 56
  • 175
  • 291
Christopher Painter
  • 54,556
  • 6
  • 63
  • 100
  • Thanks so much! I had the version only changed int the revision, but not the version number. I've modified this to now have "1.0.0", "1.0.1", "1.0.2" etc. Still, they are installed in parallel. The above link in my question says _"...Don't change the UpgradeCode for ANY upgrade, except you want that the new version can be installed in parallel to the old one. In MSI "thinking" then it is a completely new product (better understandable as upgrade path/tree)..."_. Isn't this the opposite of what you say? I'm confused – Uwe Keim Nov 28 '22 at 23:53
  • 1
    No, it's saying what I'm saying it's just really cryptic. Think Visual Studio. 2019 builds would have one Upgrade Code and 2022 builds would have another UpgradeCode. If you search Stack Overflow for two entries in add/remove programs you'll find this answered many times. Have you authored a Major Upgrade element? – Christopher Painter Nov 29 '22 at 00:05
  • 1
    PS: I have an open source project that makes all of this much easier. You can read the tutorials here and it's all setup for MajorUpgrades out of the box. https://github.com/iswix-llc/iswix-tutorials – Christopher Painter Nov 29 '22 at 00:06
  • Thanks again, Christoper. I never have a major version jump in my context, I want _every_ update to replace the previous one. So my assumption is to always keep the upgrade code and always change the product code. I'll take a more thorough look tomorrow to hopefully find the cause. – Uwe Keim Nov 29 '22 at 00:26