winget upgrade sometimes creates new installation instead of upgrading

[voltball]

Brief description of your issue

I have been going through the winget upgrade list to upgrade some pretty old software packages. On two or more occasions, I have experienced that winget upgrade has installed a new package instead of upgrading. With Mozilla products. Using Mozilla SeaMonkey as an example.

The outdated installation was installed in a custom location. A possible/probable cause might be this custom location not being known/found by winget and/or the downloaded installation program even though the program itself and it's program version was.

Steps to reproduce

winget list Firefox
Name                                Id                                     Version Available Source
---------------------------------------------------------------------------------------------------
Mozilla Firefox                     Mozilla.Firefox                        49.0.2  89.0.2    winget
SeaMonkey                           seamonkey.seamonkey                    2.40    2.53.7.1  winget
Mozilla Firefox                     Mozilla.Firefox                        89.0    89.0.2    winget

I have SeaMonkey installed? Huh. That must be pretty old. Let's upgrade it.

(This log may not be accurate on one point - I am uncertain why or even if it said "winget" behind SeaMonkey the first time I went through this tonight. If it does, it certainly indicates I have run winget 1.x on it before - if so I can't quite explain why it was outdated but no extra installation existed. )

winget upgrade SeaMonkey

Expected behavior

Expecting winget to upgrade SeaMonkey or, frankly, give an error message instead of making a new installation.

Actual behavior

Instead winget created a new SeaMonkey installation.

winget upgrade SeaMonkey
Found SeaMonkey [seamonkey.seamonkey]
This application is licensed to you by its owner.
Microsoft is not responsible for, nor does it grant any licenses to, third-party packages.
Downloading https://archive.mozilla.org/pub/seamonkey/releases/2.53.7.1/win64/en-US/seamonkey-2.53.7.1.en-US.win64.installer.exe
  ██████████████████████████████  40.4 MB / 40.4 MB
Successfully verified installer hash
Starting package install...
Successfully installed

Did that work?

winget list Firefox
Name                                Id                                     Version  Available Source
----------------------------------------------------------------------------------------------------
Mozilla Firefox                     Mozilla.Firefox                        49.0.2   89.0.2    winget
SeaMonkey                           seamonkey.seamonkey                    2.53.7.1
SeaMonkey 2.40 (x86 en-US)          SeaMonkey 2.40 (x86 en-US)             2.40
Mozilla Firefox                     Mozilla.Firefox                        89.0     89.0.2    winget

No, it created a duplicate. And the old one seems to have changed ID and name.

winget list SeaMonkey
Name      Id                  Version  Available Source
-------------------------------------------------------
SeaMonkey seamonkey.seamonkey 2.53.7.1
SeaMonkey seamonkey.seamonkey 2.40     2.53.7.1  winget

Oh, there's a mismatch in the listings. Because "Firefox" was found in tags instead of name? Never mind that, now I had a fuller, unique name for the old installation, I tried to do a more exact upgrade, like this:

winget upgrade --exact --name "SeaMonkey 2.40 (x86 en-US)"

It seems to run exactly like the previous clean install, but nothing changed. Maybe it overwrote the new duplicate.

I could not uninstall the new one in winget, since they were both found with --exact --id seamonkey.seamonkey.
I did uninstall it with Apps & features (aka Add or remove programs). After which the entire process could, and was be reproduced for documentation. Including the name and ID mismatch between "winget list Firefox" and "winget list SeaMonkey".

After uninstalling it for the 2nd time in Apps & features, I copied the download link from winget, and downloaded the installer and ran it using custom setup. I changed the installation directory to my custom directory, and it upgraded the old installation. Now it's correctly upgraded in both Apps & features and winget.

I suspect this all has to do with a previously custom install not being recognized as such, and the installer being run non-interactive, with default settings. Unfortunately the installer has probably filled in any missing info in the registry or such when it was successfully upgraded outside of winget.

I don't know enough about winget and the parameters sent to the installer, so I understand there is a chance that the fault lies in the installer not finding the existing installation, and that winget may or may not have any way to pass such info to it. I also realize that this may even be due to installation location data missing in the registry after a major Windows upgrade, or such. Still, the consequence is that winget finds a program, offers you to upgrade it, but instead you get a clean install in addition to the outdated version.

Environment

[winget --info]
Windows Package Manager v1.0.11451
Windows: Windows.Desktop v10.0.19043.1052
Package: Microsoft.DesktopAppInstaller v1.11.11451.0

[denelon]

@voltball thank you for the detailed report and steps to reproduce! I'm not sure if the parameters for specifying location would be honored by the Windows Package Manager or not. We will look into this to see if we can determine a better experience.

[denelon]

@voltball We've released WinGet 1.4 today. Several improvements have been made over the last couple of versions related to software that doesn't perform an "in place upgrade". Are you still seeing this kind of problem, or is it safe to close the Issue?

[ghost]

@voltball this issue has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 7 days. It will be closed if no further activity occurs within 7 days of this comment.