GOG Galaxy has unknown version

[BlueTooth4269]

Brief description of your issue

When installing GOG Galaxy using Winget, it does not seem to register the version correctly. After installation, it says version "unknown", still lists it in the upgrade list and reinstalls when using winget upgrade --all

Steps to reproduce

Install GOG Galaxy using winget install GOG.Galaxy -i

Expected behavior

The version should be registered correctly and not be "unknown".

Actual behavior

The version is not registered correctly and is "unknown".

Environment

winget --info
Windows Package Manager v1.0.11692
Windows: Windows.Desktop v10.0.19043.1165
Paket: Microsoft.DesktopAppInstaller v1.12.11692.0

[ItzLevvie]

GOG Galaxy doesn't display a version in Control Panel, so therefore, Windows Package Manager doesn't know what version you have installed on your machine.

It's recommended to politely contact the application developer to add the DisplayVersion key to the registry for the application.

Alternatively, if you want to partially fix this on your end, you can add the DisplayVersion key manually and make it the version number shown in winget show (or from the repository), so that way the Windows Package Manager won't be able to upgrade the application when running the winget upgrade command.

You may or will have to re-add the DisplayVersion key again every time the application automatically updates to prevent this behavior.

EDIT: Fixed typo from message below.

[robross0606]

Alternatively, if you want to partially fix this, you can add a DisplayVersion key and make it "Unknown", so that way the Windows Package Manager won't be able to upgrade the application when running the winget upgrade command. You may or will have to readd the DisplayVersion key every time the application automatically updates to prevent this behavior.

With all due respect, the fact that adding "Unknown" to a DisplayVersion key works with winget while the key missing completely does not points to at least a minor bug or improvement to winget itself. How is the key missing effectively any different than it being there with "Unknown" in it? winget should be improved to react the same in both situations.

[ItzLevvie]

Alternatively, if you want to partially fix this, you can add a DisplayVersion key and make it "Unknown", so that way the Windows Package Manager won't be able to upgrade the application when running the winget upgrade command. You may or will have to readd the DisplayVersion key every time the application automatically updates to prevent this behavior.

With all due respect, the fact that adding "Unknown" to a DisplayVersion key works with winget while the key missing completely does not points to at least a minor bug or improvement to winget itself. How is the key missing effectively any different than it being there with "Unknown" in it? winget should be improved to react the same in both situations.

There's a typo in my messages (this particular issue and previous issues), it's meant to match the version in the package from the repository rather than being set as Unknown.

When you're running winget upgrade it compares the version you've installed (from Control Panel/Registry) to the repository, since Unknown is larger than say 1.33.7, it'll always upgrade it.

So setting the version temporarily to 1.33.7 fixes it to avoid wasting internet bandwidth (because 1.33.7 == 1.33.7 and 1.33.7 != Unknown)

WinGet is still a bit far from the functionalities like Scoop or Chocolately, so there's no pre-install or post-install Batch or PowerShell scripts where DisplayVersion can be added automatically using scripts in case the application doesn't have a version in Control Panel.

Since Windows Package Manager relies purely on Control Panel & Registry - this is up to the application developer's hands and not something that can be easily handled by WinGet other than the solution below.

There's an issue somewhere being tracked to allow WinGet to ignore applications that don't provide a version, so you can put your upvote there :)

[robross0606]

There's an issue somewhere being tracked to allow people to ignore applications that don't provide a version. You can put your upvote there :)

I think you're referring to microsoft/winget-cli#1439. Not great, but something.

[SiJiL82]

I've just sent a support request to GoG asking if they can add this. Would be good if others could do the same and hopefully get it done.

[MenaceInc]

Sent a support request and this was the response I got

Hello,

Thank you for your feedback.
Our developers are already aware of this issue, unfortunately I cannot provide any ETA.
I apologise for the inconvenience.

Regards,
Cypers,
GOG Support

Not sure why it's taking longer than 6 months to update an Inno Setup file but here we are.

[persechini]

Still the same issues has not been fixed

[OfficialEsco]

Is this not "resolved" in WinGet-CLI version 1.2?
In that case if its too annoying you can install WinGet-CLI 1.3 Release Candidate

Since GOG cannot be bothered to add 1 short line of code that is the only way.

[markusdd]

I can confirm that current winget suppresses GOG Galaxy because the version string is unknown.

I also have raised another instance of the issue at GOG to make them aware of this ticket here and underline that it is an easy fix for them.

[fernandog]

I also have raised another instance of the issue at GOG to make them aware

already opened a ticked too.

In the meantime. I manually added DisplayVersion to registry

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\{7258BA11-600C-430E-A759-27E2C691A335}_is1]
"DisplayVersion"="2.0.55.99"

[nbros]

The version is available from the executable:
(Get-Item "C:\Program Files (x86)\GOG Galaxy\GalaxyClient.exe").VersionInfo

ProductVersion   FileVersion      FileName
--------------   -----------      --------
2.0.55.99        2.0.55.99        C:\Program Files (x86)\GOG Galaxy\GalaxyClient.exe

Couldn't WinGet use this as a fallback when the DisplayVersion registry key is missing?

[markusdd]

No I guess. There is thousands of applications out there and if every single one is doing it their way something like Winget will never work.

I do not see why this issue takes so long to resolve frankly. It would take a dev at GOG probably 10 minutes to put this reg key in.

[OfficialEsco]

@nbros that is actually another issue, Developers don't actually always add ProductVersion or FileVersion either, AND they can be different/incorrect...

When we complain about the DisplayVersion missing they for some reason look into the ProductVersion/FileVersion which is a different part of the installer...

The reason this takes forever is because the company simply does not care about their userbase which GOG have proven quite well lately.

[mwisnicki]

Also some software may be discontinued or have very long release cycles so the current behavior is completely unreasonable. Winget needs to handle such cases otherwise it will be forever painful to use.

[markusdd]

disagree. showing up in a package manager for user convencience should demand SOME consistency.
We're debating this as if we are asking for something outreagous here.
Just put the version in the proper place and it's fixed.

[mwisnicki]

Good luck convincing every vendor, some of which might not even exist anymore.

[markusdd]

argument besides the point. If there are no updates for the software anymore then you can just eclipse it in winget and be done. (or not install it at all, because unmaintained software will stop working at some point anyweay and is a security hazard)

[RadAd]

Installers that dont comply shouldnt be allowed in wingets repository.

It should be part of wingets acceptance criteria that after the installation winget can check the version is reporting what it thought it just installed.

[Silther]

It's now fixed.

[irzyxel]

borken again.
worked in gog 2.0.60.2, broken again in 2.0.61.63.

Name ID Version Verfügbar Quelle

GOG GALAXY GOG.Galaxy 2.0.60.2 2.0.61.63 winget

after install
GOG GALAXY GOG.Galaxy Unknown 2.0.61.63 winget

[markusdd]

yup, I also noticed that. Seems to be hard xD

[mdanish-kh]

I've noticed this is a problem in the upgrade scenario. The installer writes DisplayVersion to registry on a fresh install, but seems to somehow remove it when upgrading "in-place" from a previous version.

We can have a temporary fix for it from WinGet's side by adding UpgradeBehavior: uninstallPrevious in GOG's manifest for WinGet to invoke the uninstaller first before installing the package in the upgrade scenario. This would act as a "clean" installation and users might lose their previous configurations (if any). I've tested it manually and the DisplayVersion is set properly after the uninstall and install process.

I'm not a user of the package, so I would like to know if a "clean" install would be a problem for the users of the package

[markusdd]

This would probably not be a good thing and pretty annoying I would guess.
Would need to see for myslef what exactly it does.

[ljredux]

I can't believe this situation with GOG. Galaxy is ongoing. It's what... over two years now? Their developers are doing a sterling job of underlining why correct versioning info inclusion should be enforced if packages wish to remain in the Winget repository.

[microsoft-github-policy-service]

Hello @BlueTooth4269,

This issue has been identified as requiring a fix from a third party or external repository. Since there has been no recent activity on this issue, it will be automatically closed.

Template: msftbot/noRecentActivity/areaExternal

[microsoft-github-policy-service]

Hello @BlueTooth4269,

This issue has been identified as requiring a fix from a third party or external repository. Since there has been no recent activity on this issue, it will be automatically closed.

Template: msftbot/noRecentActivity/areaExternal