VCRedist packages are not differentiated by their architecture in IDs

[w3lld0ne]

trafficstars

Brief description of your issue

When doing winget install --id Microsoft.VCRedist.2005.x64, and then winget install --id Microsoft.VCRedist.2005.x86, only the second one (x86 in that order) is left in the system as a result. This is because winget mistakenly treats "Microsoft.VCRedist.2005.x86" and "Microsoft.VCRedist.2005.x64" as the same package and tries to "update" the first installed one. And since x86 version is actually greater than x64, winget "updates" by uninstalling x64 package and then installing x86 one (so now we have x86 package under "Microsoft.VCRedist.2005.x64" id installed).

Look at the screenshot (I've initially uninstalled every single VCRedist package for the tests):

Steps to reproduce

1. Uninstall any VCRedist in your system for a clean installation;
2. Do winget install --id Microsoft.VCRedist.2005.x64, confirm that x64 package is correctly installed (package version is 8.0.61000);
3. Do winget install --id Microsoft.VCRedist.2005.x86 and see how Microsoft.VCRedist.2005.x64 package is being "updated" to x86 (package version 8.0.61001).

Expected behavior

I want to install two packages separately, both x64 and x86.

Actual behavior

x86 package replaces x64, because winget treats them as a single ID.

Environment

Windows Package Manager v1.4.10173
Copyright (c) Microsoft Corporation. All rights reserved.

Windows: Windows.Desktop v10.0.19044.2486
System Architecture: X64
Package: Microsoft.DesktopAppInstaller v1.19.10173.0

[w3lld0ne]

Additional info:

• Providing corresponding -a x64/x86 flags doesn't change anything;
• --exact flag doesn't change anything;
• Installation using names (winget install --name "Microsoft Visual C++ 2005 Redistributable (x64)" and winget install --name "Microsoft Visual C++ 2005 Redistributable") instead of IDs doesn't change anything;
• --force flag works, x86 package installs separately with it's own ID. This is expected to be the default behaviour. However, more on this case below.

About --forced installation: Packages are installed fine, but the output from winget list vcredist and winget list "Visual C++" differs: You can see that list vcredist command displays Microsoft.VCRedist.2005.x64 ID only, however list "Visual C++" displays Microsoft.VCRedist.2005.x86 ID + some GUID instead of x64 ID (and source is not winget anymore).

[w3lld0ne]

I've also tried with other VCRedist versions, using the following script:

winget install --id Microsoft.VCRedist.2005.x64
winget install --id Microsoft.VCRedist.2005.x86

winget install --id Microsoft.VCRedist.2008.x64
winget install --id Microsoft.VCRedist.2008.x86

winget install --id Microsoft.VCRedist.2010.x64
winget install --id Microsoft.VCRedist.2010.x86

winget install --id Microsoft.VCRedist.2012.x64
winget install --id Microsoft.VCRedist.2012.x86

winget install --id Microsoft.VCRedist.2013.x64
winget install --id Microsoft.VCRedist.2013.x86

winget install --id Microsoft.VCRedist.2015+.x64
winget install --id Microsoft.VCRedist.2015+.x86

All versions are affected.

[stephengillie]

And since x86 version is actually greater than x64, winget "updates" by uninstalling x64 package and then installing x86 one (so now we have x86 package under "Microsoft.VCRedist.2005.x64" id installed).

This may help explain the scenario where a user sees an upgrade always available with VCRedist packages, and it's fixed by installing the other architecture.

• https://github.com/microsoft/winget-pkgs/issues/84721#issuecomment-1281708941

[CanePlayz]

In my case, it's unfortunately not fixed by that, when I try to install the x86 version, it says that it found no upgrade to deploy (because my x86 version is already installed and up-to-date). Since a workaround isn't optimal anyways: Is there a possible solution for this coming any time soon?