MusicBrainz Picard has wrong Version

[rhemberger]

Create issues related to the winget.exe client here

Brief description of your issue

Actual Picard Version is 2.6.3, not 2.6.30000.0
Please revert commit 04c47b5

Steps to reproduce

PS C:\WINDOWS\system32> winget upgrade
Name               ID                 Version Verfügbar   Quelle
----------------------------------------------------------------
MusicBrainz Picard MusicBrainz.Picard 2.6.3   2.6.30000.0 winget

Expected behavior

Actual behavior

Winget displays Picard as upgradable

Environment

[winget --info]
Windows Package Manager v1.0.11692
Copyright (c) Microsoft Corporation. Alle Rechte vorbehalten.

Windows: Windows.Desktop v10.0.19043.1165
Paket: Microsoft.DesktopAppInstaller v1.12.11692.0
Any other software?

[OfficialEsco]

This is a huge inconsistency from the developer
MSIX

EXE

[rhemberger]

I have apparently both installed what I never intended.
Apparently winget evaluates the DisplayVersion in the uninstall hive and ignores the MSIX value.
Imo the inconsistency is in WinGet and you should always stick to the EXE DisplayVersion.

[OfficialEsco]

WinGet uses the Metadata the Installer defines in the ARP, the inconsistency is clearly from the Developer as you can see in the Screenshots.

[rhemberger]

PS C:\WINDOWS\system32> Get-AppxPackage -AllUsers -Name "*Picard"


Name                   : MetaBrainzFoundationInc.org.musicbrainz.Picard
Publisher              : CN=Metabrainz Foundation Inc., O=Metabrainz Foundation Inc., L=San Luis Obispo, S=California,
                         C=US
Architecture           : X64
ResourceId             :
Version                : 2.6.30000.0
PackageFullName        : MetaBrainzFoundationInc.org.musicbrainz.Picard_2.6.30000.0_x64__6cfbg5p5jt8h8
InstallLocation        : C:\Program Files\WindowsApps\MetaBrainzFoundationInc.org.musicbrainz.Picard_2.6.30000.0_x64__6
                         cfbg5p5jt8h8
IsFramework            : False
PackageFamilyName      : MetaBrainzFoundationInc.org.musicbrainz.Picard_6cfbg5p5jt8h8
PublisherId            : 6cfbg5p5jt8h8
PackageUserInformation : {S-1-5-21-3768236630-1315502409-3914677840-1001 [ralfh]: Installed}
IsResourcePackage      : False
IsBundle               : False
IsDevelopmentMode      : False
NonRemovable           : False
IsPartiallyStaged      : False
SignatureKind          : Developer
Status                 : Ok

WinGet uses the Metadata the Installer defines in the ARP, so you should always stick to this value.

[rhemberger]

Reverting commit 04c47b5 should fix this for now

[OfficialEsco]

It will not as i stated in a earlier comment.

[rhemberger]

So you say 5396ff3 didn't work and 04c47b5 didn't break it? It seems that we have different ideas about working software. Sorry for bothering you.

[OfficialEsco]

2.6.3 is the EXE version, 2.6.30000.0 is the MSIX version, you have the EXE version installed, when you do winget upgrade it will not update the software, if you do winget install it will install the MSIX version.

Your previous comment also proves the current manifest is correct.

[rhemberger]

As I understand: There are 2 Picard programs, totally unrelated from a system point of view. They can exist side-by-side with different versions. winget upgrade must not report or even query the ARP-Values (EXE) for the MSIX-Package. This is a serious bug in the code imo. Furthermore I have the strong suspicion, that winget installed the MSIX-Package on my System "upgrading" from 2.6.2 to 2.6.3.
I wonder what the point of packaging the store "Picard" is. They should update automagically, unless i explicitly disable it. Then I wouldn't like it at all if winget would tamper with it.

[denelon]

@rhemberger we've encountered several programs that support side by side install for different versions. Generally an MSI or an MSIX is treated as a single package where the upgrade is only going to upgrade a package rather than install another instance.

The challenge is related to how we can be informed in a manifest when this side by side case exists. We currently attempt to upgrade with the same type of installer. In the case of an .exe supporting multiple versions side by side, we have work coming to help disambiguate what is happening. We also need a good mechanism to inform an user so they can decide if they want to keep the existing version and add the new one, or remove one or more of the existing versions to install only the latest (or the version specified).

I ran into this scenario with Ultimaker.Cura. They do have an MSI for their enterprise customers (not in this repository), but the .exe installers just add the new version. This results in multiple versions on a system, and any of the earlier versions all show an upgrade is available. The challenge here is to understand what the publisher intends, and give the customer the right information to make the informed choice if they wish to override the publishers default intended behavior.

[rhemberger]

That's not my point. I think Store Apps have their own namespace and you use Get-AppxPackage for queries (or wherever in the registry the information is stored). For classical EXE/MSI you query the ARP-Entries/Registry HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall etc.