x86 & x64 versions of the same software might cause a conflict

[Nivyan]

Brief description of your issue

As an example, if both x86 and x64 libraries of Microsoft .NET or Visual C++ are installed, the versions conflict.

Steps to reproduce

1. Uninstall both versions.
2. Install either version - observe WinGet reports the correct version.
3. Install the other version - observe WinGet reports an incorrect version.
4. Run winget upgrade --all - observe WinGet downloading and updating the packages, despite them being there already.

Exceptions: Depending on the order of installation and method, it might not recognise an update to begin with, but this means that it doesn't consider one version of the package. Additionally, if one manually installs packages in some orders, WinGet will recognise the packages - but still the wrong versions. I haven't found a correlation between which version to install in which order.

Expected behavior

Expected WinGet to differentiate between the packages.

Actual behavior

Versions conflict with each other.

Environment

Windows Package Manager v1.5.2201
Windows: Windows.Desktop v10.0.19045.3324
Package: Microsoft.DesktopAppInstaller v1.20.2201.0

Packages that's causing the errors:
Microsoft Visual C++ 2015-2022 Redistributable (x64) [Microsoft.VCRedist.2015+.x64]
Microsoft .NET SDK 7.0 [Microsoft.DotNet.SDK.7]
(And their x86 versions)

[Trenly]

This is a known issue with how winget matches Control Panel entries to available packages. The issues tagged with the Area-Matching Issue related to correlation between installed package and manifest label have a lot of great information about what exactly causes this. At a high level, winget tries to normalize package names by dropping the architecture and the version when trying to match by name, which causes issues when the packages can be installed side by side.

• Duplicate of VCRedist packages are not differentiated by their architecture in IDs #2893
• Related to Better support for Side by Side packages #2129

[microsoft-github-policy-service]

Hello @Nivyan,

We've identified this as a duplicate of another issue or PR that already exists. This specific instance is being closed in favor of the linked issue. Please add your 👍 to the other issue to raise its priority. Thanks for your contribution!

Template: msftbot/duplicate/closed