Some packages don't provide Version info, and winget upgrade constantly reports those

[cilerler]

Some packages don't provide Version info, and winget upgrade constantly reports those.

Steps to reproduce

The following snippet will install a couple of packages that I identified with the issue.

winget install LINQPad.LINQPad.5;
winget install LINQPad.LINQPad.6;
winget install Google.CloudSDK;

Expected behavior

winget upgrade should present the existing Version.

Actual behavior

It shows the version as Unknown; even itself installed the packages.

Environment

Windows Package Manager v1.0.11692
Windows: Windows.Desktop v10.0.19043.1052
Package: Microsoft.DesktopAppInstaller v1.12.11692.0

[jedieaston]

I don't know if this would be possible without winget keeping its own database on the client with a list of apps its installed, which will get out of sync with ARP table changes.

Maybe an --include-unknown flag for winget upgrade that will attempt to upgrade software with no version in the ARP table?

[cilerler]

Maybe an --include-unknown flag for winget upgrade that will attempt to upgrade software with no version in the ARP table?

@jedieaston, to make sure we are on the same page, WinGet already tries to upgrade the packages which report status as Unknown; the problem is "we don't want it to upgrade" when the available version is the existing version. And as you said in the first sentence, the workaround could be a local database, but I don't think it is a permanent solution for the reason you stated.

If you install LINQPad.LINQPad.6, it will install the version 6.13.13, and then if you write winget upgrade, it will give you the list above, which shouldn't since the installed version is already the available latest one.

[jedieaston]

Oh, I should’ve made it a bit more clear. WinGet shouldn’t try to upgrade software with version unknown unless some kind of —include-unknown flag is set. Ideally, a warning would be shown if there was software with unknown versions when winget upgrade is called, something like “3 apps have unknown versions. Add the —include-unknown flag to include them”. NPM and apt do a similar thing when they have to warn a user about a possibly needed argument.

(I’ve seen this behavior before, sorry for the confusion)

[cilerler]

Oh, I see your point now, correct it would be nice, and it may solve part of the problem.
However, my expectation for this issue is somehow WinGet to not show Unknown at all. (I mean it should be able to identify it one way or another)

[marsfan]

What method does winget use to determine app version? I would have expected it to query the properties of the program, but that does not seem to be the case, as winget shows the version as unknown for GPU-Z (techpowerup.gpu-z), while the actual application executable properties show 2.40.0.0 for both Product Version and File Version.

[OfficialEsco]

What method does winget use to determine app version? I would have expected it to query the properties of the program, but that does not seem to be the case, as winget shows the version as unknown for GPU-Z (techpowerup.gpu-z), while the actual application executable properties show 2.40.0.0 for both Product Version and File Version.

It uses the ARP (Add and Remove Programs) information, which then is tied to the Registry keys. This is nothing new so this is the Developers fault.

[jedieaston]

actual application executable properties show 2.40.0.0 for both Product Version and File Version.

See, if they are going through the trouble of setting the executable's properties I wonder why they aren't going through the trouble of setting the ARP table. Maybe that's something for the Windows packaging team to ask ISVs, because I can't imagine it's that much more work to publish it in a different place.

It's possible winget could read the executable's version, but it would have to know where it is, and right now winget doesn't track where installers spew files (that would be a gigantic hassle and probably is outside of the scope for the tool, except for portable apps, of course).

[denelon]

We're discussing a few different approaches for dealing with Apps that don't report the installed version. We thought about using something like auto-pinning these packages, but that sets a confusing precedent if the developer pinned a package, and it upgraded itself. We may not be able to pin these packages. The last round of notes is on #1163

[JiiPee74]

I think simplest way is just exclude software what doesn't store version info to registry. After all program developer is the one who should fix their programs and write that information.

I was thinking that it would be possible to query version on the fly by 1st using registry query to find where executable is and then doing PS Get-Item VersionInfo against executable. But 2 out of 3 installed programs what report version unknown was success. Geekbench 5 was failure. It doesn't store it's version in executable meta, so even that is not an option because it won't catch all.

[Nejat]

As a temporary workaround, until there is a better solution, I created a PowerShell script to skip Unknowns.

If you use it without the -upgrade flag it will tell you what it intends to do.

It can also read a skip file for a list of packages not to upgrade, for instances I use it to skip instances of Unity or Visual Studio. Skip functionality defaults to reading a file called winget-skiplist, but the script allows you to provide your own skip file.

PS Script
https://gist.github.com/Nejat/6cb42f098320cb2fcb57a4e1728ca29e

Skip Text File I Use
https://gist.github.com/Nejat/620f6598dce03ea9b7a4f49e6a5164c8

Maybe it might help meanwhile

[ThioJoe]

I've figured out a workaround especially if you have only a couple offending programs: Manually change the registry entry to add the version number yourself.

1. In Regedit, find the key/folder for the relevant program. I've found program installation entries are listed in one of these places (not sure if there's any other locations):

• Computer\HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\
• Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall
• Computer\HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall

2. Find the one for the program and click it to view the values (whatever the data is called on the right side). For example look for "DisplayName" which basically every program should have, to know you're in the right place.

3. Then just right click to create a new String Value called "DisplayVersion", then double click to change the value to whatever is the correct version number you want. It should now show in both Add/Remove Programs and in Winget.

Note: If the offending program is on Github you might wish to just go on there, find whatever configuration file the developer is using that creates these entries (like an .nsi file for NSIS), and make a pull request to show them how to add version number. It probably already have a list of other registry entries it's making so you just create a new one for DisplayVersion. (Technically I think it's best practice to also include keys called 'versionMajor' and 'versionMinor' if you want)

[denelon]

@cilerler,

This feature was implemented by @jedieaston and is available in the 1.2 Release Candidate.

[cilerler]

@denelon Unfortunately, I don't think it applies to this one

[jedieaston]

*1.3 preview release. It wasn't present in the 1.2 release candidate.

https://github.com/microsoft/winget-cli/releases/tag/v1.3.431

[vampiricwulf]

I feel like, while this is a developer issue, it should also be addressed on this end where if you run an upgrade through this, that it should keep track of the last installed version so that running winget upgrade --all it would have an internal check to skip them.

(Sorry for revive, but I feel it's related and not worth making a new issue over.)

[OfficialEsco]

I feel like, while this is a developer issue, it should also be addressed on this end where if you run an upgrade through this, that it should keep track of the last installed version so that running winget upgrade --all it would have an internal check to skip them.

I do actually agree, but i don't think Microsoft wants to do it that way, winget-cli could simply make a new string called WinGetVersion if DisplayVersion is not present, but i think there are security issues and breakable issues by doing that.