microsoft
VCRedist 2010 full version number not detected by Winget
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
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.
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.
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.
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
.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