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)

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.)

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)

*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

@cilerler,

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

It does not look like you’ve installed the 1.2 Release Candidate.

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

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?