Open lunacd opened 1 year ago
@denelon - This is especially interesting since the manifest over at winget-pkgs does include AppsAndFeaturesEntries with the display version as 5.15.7 (20303)
, along with the Display Name, Product Code, and Upgrade Code (for the msi).
It seems that the msstore installs the exe version, which writes the exact same AppsAndFeatures data of the x64 exe that is in the manifest at winget-pkgs.
PS C:\Windows\system32> winget install XP99J3KP4XZ4VV -s msstore
Found Zoom - One Platform to Connect [XP99J3KP4XZ4VV] Version Unknown
This application is licensed to you by its owner.
Microsoft is not responsible for, nor does it grant any licenses to, third-party packages.
| <Package agreements - Accepted>
Downloading https://sparkcdnwus2.azureedge.net/cachedpackages/8e376d36-34a3-46aa-93a1-e82709b19566_97bc057dee083684ba09841bf262ed9082765ae3bd2c58b7fb99e470121bf86a
██████████████████████████████ 69.7 MB / 69.7 MB
Successfully verified installer hash
Starting package install...
Successfully installed
PS C:\Windows\system32> Get-ARPTable
DisplayName DisplayVersion Publisher ProductCode
----------- -------------- --------- -----------
Microsoft Edge 92.0.902.67 Microsoft Corporation Microsoft Edge
Microsoft Edge Update 1.3.147.37 Microsoft Edge Update
Zoom 5.15.7 (20303) Zoom Video Communications, Inc. ZoomUMX
Here is the log from winget upgrade --verbose
- WinGet-2023-08-18-12-40-43.883.log
It's very odd that even though the AppsAndFeaturesEntries are specified, and are an exact match, it still isn't preventing the upgrade (regardless of the switch in source).
Based on the manifests in winget-pkgs, the parenthetical may be some form of build number, but it isn't required to differentiate between two released versions. That is the good part.
The version comparison code explicitly orders an empty non-numeric portion of a version field higher than a non-empty one. That is to say 5.15.7 (20303)
will be ordered lower than 5.15.7
because there is no non-numeric portion of the field after the 7
. This is the bad part, and it was done explicitly to prevent cases where the non-numeric portion was a modifier (like a locale) from looking like upgrades to the base version (but that was a band-aid).
I think that the next investigation step is to see why the display version code didn't kick in here, although I'm probably not remembering something about the design of that.
One thing that we could do here with a code change is to treat parentheticals in versions as empty (ie 5.15.7 (20303)
is equivalent to 5.15.7
). That would require the winget-pkgs manifests to drop the 4th version field as well. We might have enough data to determine whether this is safe, but it would probably take some digging to get it.
I think that the next investigation step is to see why the display version code didn't kick in here, although I'm probably not remembering something about the design of that.
Interestingly, when manually installing the exe outside of winget using the URL in the winget-pkgs manifest, the issue doesn't occur. However, I copied the download URL from the store API response and visited it in a browser. After downloading the package, I renamed it with the .exe extension - but the hash is different from any of the hashes in the winget manifests. Installing this exe manually does cause the issue, although the product code remains ZoomUMX
, the ID does show as XP99J3KP4XZ4VV
despite being installed from outside of winget.
I decided to dig a little deeper and inspected the contents of the exe files - both the renamed one from the msstore package and the one from the winget-pkgs url. Each downloaded package contains two files - Installer.exe
and ZoomFull_Sip.cab
. Comparing the two, both installer files have the same hash and both cab files have the same hash. So why is the hash of the overall package different? It seems the version downloaded from the msstore has an extra 8 bytes which directly correlate to the automatic inclusion of the /silent
switch when calling the embedded installer.exe.
So, I rebooted into a clean sandbox, downloaded the package using the URL in the winget-pkgs manifest, and then used 7-zip to extract the installer.exe
and ZoomFull_Sip.cab
into a new folder. I then double clicked to run the installer.exe, and it ran without issue. Opened up PowerShell, and ran winget upgrade
, this did cause the issue described above. The ID showed as the msstore ID, but upgrade showed a version available from the winget source.
I'm not sure why the packaged installers seem to impact the end result of how Winget detects the packages - but it does, even though the AppsAndFeaturesEntries appear to be the same.
TL;DR -
installer.exe
- Issue occurred
Brief description of your issue
winget expects a version string like 5.15.7.20303 but sees a version string of 5.15.7 (20303). winget then incorrectly flags this package as upgradable.
Steps to reproduce
Expected behavior
winget should not flag zoom as upgradable.
Actual behavior
winget thinks zoom is not up to date.
Environment