Multiple same name packages appeared right after the package upgrade

[cilerler]

Brief description of your issue

I just upgraded a package and end up with multiple different versions of the package

Steps to reproduce

type winget upgrade Microsoft.SQLServerManagementStudio and then type winget upgrade

Expected behavior

no result should include Microsoft.SQLServerManagementStudio

Actual behavior

Name                                   Id                                     Version        Available      Source
------------------------------------------------------------------------------------------------------------------
Microsoft SQL Server Management Studio Microsoft.SQLServerManagementStudio    2.3.28307      15.0.18410.0   winget
Microsoft SQL Server Management Studio Microsoft.SQLServerManagementStudio    12.0.40664.0   15.0.18410.0   winget
Microsoft SQL Server Management Studio Microsoft.SQLServerManagementStudio    1.36.1         15.0.18410.0   winget
Microsoft SQL Server Management Studio Microsoft.SQLServerManagementStudio    14.29.30133.0  15.0.18410.0   winget
Microsoft SQL Server Management Studio Microsoft.SQLServerManagementStudio    14.29.30133.0  15.0.18410.0   winget
Microsoft SQL Server Management Studio Microsoft.SQLServerManagementStudio    1.35.0         15.0.18410.0   winget
Microsoft SQL Server Management Studio Microsoft.SQLServerManagementStudio    11.4.7462.6    15.0.18410.0   winget
Microsoft SQL Server Management Studio Microsoft.SQLServerManagementStudio    12.0.40664.0   15.0.18410.0   winget

Environment

Windows Package Manager (Preview) v1.3.1251-preview
Copyright (c) Microsoft Corporation. All rights reserved.

Windows: Windows.Desktop v10.0.22000.613
System Architecture: X64
Package: Microsoft.DesktopAppInstaller v1.18.1251.0

Logs: %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\DiagOutputDir

Links
---------------------------------------------------------------------------
Privacy Statement   https://aka.ms/winget-privacy
License Agreement   https://aka.ms/winget-license
Third Party Notices https://aka.ms/winget-3rdPartyNotice
Homepage            https://aka.ms/winget
Windows Store Terms https://www.microsoft.com/en-us/storedocs/terms-of-sale

[Trenly]

Related to #2137

cc @JohnMcPMS https://github.com/microsoft/winget-cli/pull/2137#issuecomment-1118884538

[denelon]

It is also possible to some extent that Microsoft SQL Server Management Studio allows side by side installation of major versions rather than just upgrading the existing version. I could certainly see challenges with preserving connection strings if the default upgrade behavior was "uninstallPrevious".

[JohnMcPMS]

I suggested on the PR that we should just use the local name for list because of how they are using this in the manifest. There are still going to be ... issues ... with targeting these for uninstall, but at least list won't be confusing.

In addition, it does appear that it supports SxS installs, so this would be the fun case for adding support for both SxS and multi-component packages.

[Mertsch]

This has been improved in v1.3.1391-preview but is still bugged

Name                                                         Id                                  Version      Available    Source
---------------------------------------------------------------------------------------------------------------------------------
Microsoft Help Viewer 2.3                                    Microsoft.SQLServerManagementStudio 2.3.28307    15.0.18410.0 winget
Microsoft Visual C++ 2013 Redistributable (x64) - 12.0.40664 Microsoft.SQLServerManagementStudio 12.0.40664.0 15.0.18410.0 winget
Azure Data Studio (User)                                     Microsoft.SQLServerManagementStudio 1.36.2       15.0.18410.0 winget
Microsoft SQL Server 2012 Native Client                      Microsoft.SQLServerManagementStudio 11.4.7462.6  15.0.18410.0 winget
Microsoft Visual C++ 2013 Redistributable (x86) - 12.0.40664 Microsoft.SQLServerManagementStudio 12.0.40664.0 15.0.18410.0 winget

[yooakim]

I have the same issue as reported above:

Name                                   Id                                  Version      Available    Source
-----------------------------------------------------------------------------------------------------------
Microsoft SQL Server Management Studio Microsoft.SQLServerManagementStudio 2.3.28307    15.0.18420.0 winget
Microsoft SQL Server Management Studio Microsoft.SQLServerManagementStudio 12.0.40664.0 15.0.18420.0 winget
Microsoft SQL Server Management Studio Microsoft.SQLServerManagementStudio 1.36.2       15.0.18420.0 winget
Microsoft SQL Server Management Studio Microsoft.SQLServerManagementStudio 11.4.7462.6  15.0.18420.0 winget
Microsoft SQL Server Management Studio Microsoft.SQLServerManagementStudio 12.0.40664.0 15.0.18420.0 winget
5 upgrades available.

Winget info as follows:

C:\Users\yooak\Downloads>winget -v --info
Windows Package Manager (Preview) v1.3.1251-preview
Copyright (c) Microsoft Corporation. All rights reserved.

Windows: Windows.Desktop v10.0.22000.708
System Architecture: X64
Package: Microsoft.DesktopAppInstaller v1.18.1251.0

Logs: %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\DiagOutputDir

Links
---------------------------------------------------------------------------
Privacy Statement   https://aka.ms/winget-privacy
License Agreement   https://aka.ms/winget-license
Third Party Notices https://aka.ms/winget-3rdPartyNotice
Homepage            https://aka.ms/winget
Windows Store Terms https://www.microsoft.com/en-us/storedocs/terms-of-sale

[brianary]

I'm also getting too many packages marked as Microsoft.SQLServerManagementStudio, resulting in an enormous, superfluous download every time I run winget upgrade --all.

Name                                     Id                                  Version        Available      Source
-----------------------------------------------------------------------------------------------------------------
Microsoft Help Viewer 2.2                Microsoft.SQLServerManagementStudio 2.2.23107      15.0.18420.0   winget
Microsoft Help Viewer 2.3                Microsoft.SQLServerManagementStudio 2.3.28307      15.0.18420.0   winget
Microsoft SQL Server 2012 Native Client  Microsoft.SQLServerManagementStudio 11.4.7462.6    15.0.18420.0   winget

My winget info:

Windows Package Manager (Preview) v1.3.1391-preview
Copyright (c) Microsoft Corporation. All rights reserved.

Windows: Windows.Desktop v10.0.19044.1706
System Architecture: X64
Package: Microsoft.DesktopAppInstaller v1.18.1391.0

Logs: %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\DiagOutputDir

Links
---------------------------------------------------------------------------
Privacy Statement   https://aka.ms/winget-privacy
License Agreement   https://aka.ms/winget-license
Third Party Notices https://aka.ms/winget-3rdPartyNotice
Homepage            https://aka.ms/winget
Windows Store Terms https://www.microsoft.com/en-us/storedocs/terms-of-sale

[jedieaston]

@denelon I think this needs to be fixed before 1.3 is generally available, as it's a showstopper for adding AppsAndFeaturesEntries to manifests (since this will result in infinite upgrades for any manifest where all of the ARP entries don't have the same exact version number).

Steps to reproduce:

1. winget install Microsoft.SQLServerManagementStudio, which installs the latest version.
2. winget upgrade, and see that the components that were just installed need upgrades.

I proposed https://github.com/microsoft/winget-cli/issues/2186 as a possible solution, but since schema changes aren't possible this late in the game, is there an easier solution for the time being? I feel like if we know that "Azure Data Studio" exists in the AppsAndFeaturesEntries list for that package, we should be able to just compare the version from the component in the list instead of comparing to the version of the package. I haven't looked at that code in a minute though, so I can't remember if that's really easy.

(Of course, the better matching via AppsAndFeaturesEntries could also just be hidden behind an experimental flag, but I'd prefer if we didn't have to do that as then we'd have to delay it being generally available until 1.4).

[denelon]

Paraphrasing @johnmcpms:

Having multiple entries in the manifest enables this kind of scenario that the code was never prepared for.

Full support for having multi-component packages is probably an all of 1.4 kind of deliverable. It might even be a 2.0 kind of feature, depending on what we would want to do with it and how much impact that would have on the rest of things.

It might be best to limit to a single entry for Apps & Features per installer node. I don't believe we gain anything with multiple entries until the client can properly reason about them.

[jedieaston]

It might be best to limit to a single entry for Apps & Features per installer node.

That's fairly similar to how it is today, except instead of the ARP name needing to equal the PackageName, we can keep the ARP name in AppsAndFeaturesEntries. An improvement, no doubt, even if it wasn't what we were hoping for (and @JohnMcPMS is totally right, multi-component packages do create a ton of questions).

Unfortunately, it won't correct the matching issues for most (all?) of the apps that needed AppsAndFeaturesEntries. JetBrains apps, for instance, where the "marketing" version number is different than the ARP version number. With the current behavior, changing the PackageVersion to the marketing version number and adding the ARP entry to AppsAndFeaturesEntries would result in buggy upgrade behavior (since version 228.x.y is less than 2022.3.1, for instance). We use the ARP version number for JetBrains apps in the PackageVersion field right now, but that causes user confusion because JetBrains doesn't refer to it with that version number in their docs.

I think my original thinking when writing up https://github.com/microsoft/winget-cli/issues/1073 was that the components themselves shouldn't be used for comparisons when figuring out upgrades[1], but just as another way of matching to a specific package and version. Then that package we matched to would be used for comparing for upgrades. The way it is right now, winget is treating each component like it's a separately installed version of the package.

Now that I'm writing it out, this is way more complicated than I thought before writing this comment. Anyway, long story short, I'm not certain that allowing a single AppsAndFeaturesEntry corrects any problems that we haven't already worked around (at least in the community repo). I am certain that it might be time to write a spec :)

---

[1]. Tangent: It kind of helped me to write out the logic, maybe it will help someone else:

Finding an upgrade:

1. search repo for packages with AppsAndFeaturesEntry "Microsoft Bob version 1.2.3"
2. order by number of AppsAndFeaturesEntries (i.e. packages that just install Microsoft Bob are more likely to have installed Microsoft Bob than packages that install Microsoft Bob and 50 other things)
3. pick the one with the least ARP entries, that's the package we use for evaluating upgrades.

So: Microsoft Bob version 1.2.3 might have been installed by Microsoft.AliceAndBob version 2.0.0, and there's a version 2.0.1 available. The client should say "Microsoft.AliceAndBob version 2.0.0 < 2.0.1", not "Microsoft Bob version 1.2.3 < 2.0.1", since Bob is just a component of Microsoft.AliceAndBob,

There's still some corner cases of the logic missing though, like what if the component's version didn't change in the new version of the package (we probably don't care, still show a upgrade)? Or do we still match if the closest package we can find has a bunch of AppsAndFeaturesEntries that aren't present locally (like if the user customized their install)? And this isn't trivial to implement at all :(

[denelon]

Yes, this project is often filled with deeply complex problems to solve. I'm so glad to have so much community support to help us refine our thinking, and to look around corners.

I do tend to try and take the next bite out of each problem to make a determination on the most common path, and look for what settings/arguments give users more control over behaviors.

I'm looking at DotNet as one of the current examples where a "productVersion" and a "displayVersion" are different. I want to make sure I can show a user the "productVersion" and use the "displayVersion" for comparison in the upgrade flow.

Note for others. The "productVersion" is the top-level value used to organize manifests and show which versions are available. The "displayVersion" represents the version displayed in Windows Apps & Features below the "Name" and represents more of what the Windows Package Manager uses for logical version comparison:

My hope is that it leads us down the path to success for other packages like JetBrains.

[JohnMcPMS]

JetBrains apps, for instance, where the "marketing" version number is different than the ARP version number. With the current behavior, changing the PackageVersion to the marketing version number and adding the ARP entry to AppsAndFeaturesEntries would result in buggy upgrade behavior (since version 228.x.y is less than 2022.3.1, for instance). We use the ARP version number for JetBrains apps in the PackageVersion field right now, but that causes user confusion because JetBrains doesn't refer to it with that version number in their docs.

@yao-msft has already implemented a solution for this that enables marketing version to be used for PackageVersion and the AaFE DisplayVersion to be used for comparison with the ARP data.

[Cyberavater]

Rustup: the Rust toolchain installer Rustlang.Rustup Unknown 1.25.5    winget
1 upgrades available.

Please check this one.

[Trenly]

Rustup: the Rust toolchain installer Rustlang.Rustup Unknown 1.25.5    winget
1 upgrades available.

Please check this one.

That is an unrelated issue. The publisher is not setting a display version in the ARP entries. See https://github.com/microsoft/winget-pkgs/issues/67393

[Cyberavater]

Unrelated, but the Windows Terminal version on Winget is behind the current version, can you fix it?

[Masamune3210]

Terminal doesn't have its own anything, it just is a frontend to command processors like PowerShell and cmd

[Masamune3210]

I completely misunderstood the last comment, my bad. Thought they meant that Terminal had its own version of winget. Don't try to tech right after waking up lol

[denelon]

I completely misunderstood the last comment, my bad. Thought they meant that Terminal had its own version of winget. Don't try to tech right after waking up lol

For me, I need to add "or having that first cup of coffee" 😊

[denelon]

Unrelated, but the Windows Terminal on winget version is behind the current version, can you fix it?

Windows Terminal updates their packages as they release. There is currently an issue for Windows 10 users as the latest version only support Windows 11. The current workaround is winget show Microsoft.WIndowsTerminal --versions then one can specify the version to install. It's generally the one before the latest.

[cilerler]

Any idea when this issue will be resolved?

[Trenly]

Any idea when this issue will be resolved?

For SSMS it should already be resolved. You may have to clear your installed.db file by uninstalling and re-installing winget, and making sure you are on the latest stable version or higher

[cilerler]

@Trenly, thanks for the quick reply. Unfortunately, uninstalling it from the Apps & features is not working, is there any way you know how to deleted installed.db manually?

[Trenly]

@Trenly, thanks for the quick reply. Unfortunately, uninstalling it from the Apps & features is not working, is there any way you know how to deleted installed.db manually?

In powershell you should be able to run Remove-AppxPackage Microsoft.DesktopAppInstaller, or if you clone the winget-pkgs repo you can use the Powershell Script ./Tools/WingetVersionManager -Latest -Clean

[cilerler]

Uninstall didn't work 😞

And, I deleted the installed.dbs manually from 🤯

• "$env:userprofile\AppData\Local\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\StoreEdgeFD\installed.db"
• "$env:userprofile\AppData\Local\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\Microsoft.Winget.Source_8wekyb3d8bbwe\installed.db"

and so far it stopped working at all 😢

[jedieaston]

Maybe try winget source reset --force? That'll wack the source entirely and reinstall it. (you'll have to be an Administrator)

[JohnMcPMS]

And, I deleted the _installed.db_s manually from 🤯

• "$env:userprofile\AppData\Local\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\StoreEdgeFD\installed.db"
• "$env:userprofile\AppData\Local\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\Microsoft.Winget.Source_8wekyb3d8bbwe\installed.db"

This should be fine, with predictable (and acceptable) results. They should not have any effect on your ability to refresh the source. That is likely a separate issue, and the logs from the refresh attempt (or a new one) would be helpful.

[cilerler]

Maybe try winget source reset --force? That'll wack the source entirely and reinstall it. (you'll have to be an Administrator)

@jedieaston, I did it already.

This should be fine, with predictable (and acceptable) results. They should not have any effect on your ability to refresh the source. That is likely a separate issue, and the logs from the refresh attempt (or a new one) would be helpful.

@JohnMcPMS, I was going to send you that but had to restart, and it started to work

@Trenly, after deleting those two files, and a restart, I confirm that it fixed the issue.

Thanks all! 🤗

[cilerler]

That said, I realized that, issue is still happening for DotNet packages as shown below.

[jedieaston]

That looks like https://github.com/microsoft/winget-cli/issues/2408. (Which is kind of a different issue than this one, because #2408 describes multiple packages being identified as the same package, whereas this one identifies one package showing up multiple times)

[Cyberavater]

It's happening again for Pycharm Professional.

[jedieaston]

Can you post the output of winget list pycharm please?