[Package Issue]: EPOS.EposConnect

[jaimetuitorres]

Please confirm these before moving forward

• I have searched for my issue and not found a work-in-progress/duplicate/resolved issue.
• I have not been informed if the issue is resolved in a preview version of the winget client.

Category of the issue

Other

Brief description of your issue

when I run winget upgrade the installed version of EPOS.EposConnect is not displaying the current version.

EPOS Connect
EPOS. EposConnect
< 7.9.0 (installed version)
7.9.0

Steps to reproduce

install a previous version of Epos (for example 7.8.2) and run winget upgrade and you will see that the installed version detected shows like "< 7.9.0"

Actual behavior

run winget upgrade and you will see that the installed version detected shows like "< 7.9.0"

Expected behavior

run winget upgrade and you will see that the installed version detected shows like "7.8.2"

Environment

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

Windows: Windows.Desktop v10.0.22631.4169
System Architecture: X64
Package: Microsoft.DesktopAppInstaller v1.23.1911.0

Winget Directories
-------------------------------------------------------------------------------------------------------------------------------
Logs                               %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\DiagOutputDir
User Settings                      %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\settings.json
Portable Links Directory (User)    %LOCALAPPDATA%\Microsoft\WinGet\Links
Portable Links Directory (Machine) C:\Program Files\WinGet\Links
Portable Package Root (User)       %LOCALAPPDATA%\Microsoft\WinGet\Packages
Portable Package Root              C:\Program Files\WinGet\Packages
Portable Package Root (x86)        C:\Program Files (x86)\WinGet\Packages
Installer Downloads                %USERPROFILE%\Downloads

Links
---------------------------------------------------------------------------
Privacy Statement   https://aka.ms/winget-privacy
License Agreement   https://aka.ms/winget-license
Third Party Notices https://aka.ms/winget-3rdPartyNotice
Homepage            https://aka.ms/winget
Windows Store Terms https://www.microsoft.com/en-us/storedocs/terms-of-sale

Admin Setting                             State
--------------------------------------------------
LocalManifestFiles                        Disabled
BypassCertificatePinningForMicrosoftStore Disabled
InstallerHashOverride                     Disabled
LocalArchiveMalwareScanOverride           Disabled
ProxyCommandLineOptions                   Disabled
DefaultProxy                              Disabled

Screenshots and Logs

[stephengillie]

It appears that version 7.9.0 is the only version currently described by a manifest in this repo. The package manager operates by matching manifests in this repo with data in the Registry. Here, it has a partial match - it can match the PackageIdentifier, but not to a specific version described in the repo, so it can't be sure that the version data is accurate. What if it's a manifest that has a DisplayVersion to differentiate the version number displayed by the package from the number written to Registry?

In this situation, the package manager displays the less-than chevron < followed by the lowest version number in a manifest in the repo. Here, the lowest version number is 7.9.0, so the output is acccurate. It's technically not a bug as this is intended program operation.

This is closer to a feature request, to display the version number in Registry instead of the "chevron-lowest version number" system currently used.

[Trenly]

I think a manifest change does also solve this though @stephengillie - Since there is only one version in the Repo, there should be no need for AppsAndFeaturesEntries

[a-mnich]

@Trenly I've initially added the ARP entries as EPOS does not use the full display versions on their website and in the changelogs, but besides that I don't see any reason why we shouldn't use the full versioning as PackageVersion. Additionally, setting a different publisher in the AppsAndFeatures entries was quite unfortunate.

However on a technical level I'm genuinly interested why removing the ARP entry leads to better package matching here.
With the PR, the Publisher and DisplayVersion are basically only moved from the ARP entry to the top level of the manifest. In this case, this should basically lead to the same data basis for matching the package as before. Only the product code isn't available anymore, which should theoretically not be benefical as it would ideally be a unique identifier for a product release.
Is there any documentation on the exact package matching logic as it's currently implemented in the winget-cli?

[Trenly]

As far as I know, there isn't a ton of great documentation outside of a few comments on threads here or there.

The basics of it is that normally, PackageVersion, Publisher, and PackageName from the Locale manifest, along with the ProductCode from the installer are used for correlation. This works fine in most cases, but not all. So, if the package writes a different DisplayVersion key into the registry, then the AppsAndFeaturesEntries can be used to force the matching to whatever the application actually writes. This is extremely useful when -

• Different installer types (e.g exe and msi) write different versions to the registry
• A single installer writes multiple AppsAndFeaturesEntries
• The version used on the website and release notes is wildly different from what is written to the registry (e.g 1.5.3.2 vs 5.3.2)

However, when the DisplayVersion key is present, WinGet will create a VersionRange for each PackageVersion and use all of the DisplayVersion to populate the start and end of the range. This way, if a publisher releases 3.5.0 but uses 3.5.0.1001 for the exe installer and 3.5.0.1003 for the msi installer, then an installer that WinGet doesn't know about could write 3.5.0.1002 and it would still be mapped correctly into version 3.5.0

This is what introduces the problem, though. By creating the VersionRange, WinGet switches to a mapping logic instead of an ordering logic. Normally, WinGet just compares to see if Version A is greater than Version B. When using the VersionRange, WinGet checks to see if Version A is greater than, less than, or within the range specified for Version B. Since the ranges are being used, WinGet can't map the DisplayVersion into a specific PackageVersion unless the manifest also exists for that specific version; so instead, WinGet represents that the installed version is lower than the latest version it knows about. Or, in some cases, it could be higher than the latest version it knows about. Only if there is an existing manifest where the VersionRange matches what is installed will WinGet show the actual installed version if the DisplayVersion key is present in any version of the package (this is why if any one manifest for a package has DisplayVersion, they must all be updated to have DisplayVersion)

[a-mnich]

@Trenly Thank you for the very detailed explanation! Apprecciate it!
Now knowing where this behavior was coming from and what I was looking for, I found the original spec that basically exactly describes what you just explained. #980 - Apps and Features entries version mapping

[stephengillie]

As far as I know, there isn't a ton of great documentation outside of a few comments on threads here or there.

This documents the situation very clearly. Were this to go into the documentation, where would be the best place? Would you be willing to add a section like this?