VCRedist 2010 full version number not detected by Winget

[o-l-a-v]

Brief description of your issue

Latest VCRedist 2010 x64 in winget-pkgs is 10.0.40219.

• https://github.com/microsoft/winget-pkgs/tree/master/manifests/m/Microsoft/VCRedist/2010/x64
• (This is actually 10.0.40219.**325**)

Problem is that there have been several releases 10.0.40219.x, but Winget does not seem to detect the 4th version number position. Newest right now: 10.0.40219.473.

• https://github.com/abbodi1406/vcredist/tree/master/source_links#microsoft-visual-c-2010-redistributables---v10
• https://learn.microsoft.com/en-us/cpp/windows/latest-supported-vc-redist?view=msvc-170#visual-studio-2010-vc-100-sp1-no-longer-supported

Output from winget list vcredist

C:\Users\olavb>winget list vcredist
Name                                                               Id                           Version       Source
---------------------------------------------------------------------------------------------------------------------
Microsoft Visual C++ 2013 Redistributable (x86) - 12.0.40664       Microsoft.VCRedist.2013.x86  12.0.40664.0  winget
Microsoft Visual C++ 2015-2022 Redistributable (x86) - 14.34.31931 Microsoft.VCRedist.2015+.x86 14.34.31931.0 winget
Microsoft Visual C++ 2015-2022 Redistributable (x64) - 14.34.31931 Microsoft.VCRedist.2015+.x64 14.34.31931.0 winget
Microsoft Visual C++ 2010  x64 Redistributable - 10.0.40219        Microsoft.VCRedist.2010.x86  10.0.40219    winget

C:\Users\olavb>

Adding a newer version to winget-pkgs probably would likely not offer users with previous versions installed an upgrade.

This behavior from Winget is probably expected, because the uninstall info written by the installer to the registry does not include the full version number (DisplayVersion).

Screenshot from registry

A workaround to get full version info is:

Get-ItemPropertyValue -Path 'Registry::HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\VisualStudio\10.0\VC\VCRedist\x64' -Name 'Version'

Anyways, is there anything winget-cli can do, or should do, to be able to catch edge cases like this? Add ability for custom detection methods maybe?

Steps to reproduce

Install: winget install --id Microsoft.VCRedist.2010.x64 --silent
List: winget list Microsoft.VCRedist.2010.x64

Expected behavior

Full version number is displayed.

Actual behavior

4th digit/position of the version number is missing, thus can't validate whether newer versions are available.

Environment

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

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

[stephengillie]

Since the version number in the current manifest is missing its 4th tuple, this should be updated to append .325.

Since a new version 10.0.40219.473 is available, a new manifest for it should be submitted, so it can be installed with Winget.

[denelon]

I'm not sure that's the best solution here.

WinGet is going to use the "displayVersion" from Windows Apps & Features for comparison.

If the installer isn't writing the full value to the registry, the comparison logic will create a false positive for the latest version being installed for any users with an earlier version where the reported value matches.

[Trenly]

If the installer isn't writing the full value to the registry, the comparison logic will create a false positive for the latest version being installed for any users with an earlier version where the reported value matches.

I believe it's actually even worse than that - creating a false negative. Versions are treated as if they have an infinite number of trailing .0. This is why 1.0.0 and 1.0 are considered equal. I believe what would end up happening if the 4th number was set would be that the PackageVersion would always be greater than the DisplayVersion, since 10.0.40219.473 is greater than 10.0.40219.0 (Trailing 0 shown for clarity), which would result in an upgrade loop.

[o-l-a-v]

That's different from how .NET treats version numbers, where 1.0.0 would be considered newer than 1.0.

If sorting [System.Version[]]('1.0','1.0.0') descending, 1.0.0 ends on top. And [system.version]('1.0') -eq [system.version]('1.0.0') is $false

[stephengillie]

.NET version numbers appear to have 4 tuples, and fill with -1s when not specified:

PS C:\> [System.Version]'1.0'
Major  Minor  Build  Revision
-----  -----  -----  --------
1      0      -1     -1

PS C:\> [System.Version]'1.0.0'
Major  Minor  Build  Revision
-----  -----  -----  --------
1      0      0      -1