[BUG] Winget unable to identify current version, and delayed updates

[Sollaze]

Version

6.3.0 and below

Windows Version

Windows 10 Pro 22H2

Actual Behaviour

As you can see in the screenshot below, winget is unable to identify the current version of the application and is also behind on the release versions (at least for some time).

Expected Behaviour

Ideally, winget should be able to determine the current application version but it would also be great if it could detect (or deliver) updates as fast as the app's built-in update checker.

Reproduction Steps

No response

Log

No response

[radj307]

https://github.dev/radj307/volume-control/blob/main/.github/workflows/winget.yml
https://github.com/radj307/volume-control/actions/runs/6635807157/job/18027310670
https://github.com/vedantmgoyal2009/winget-releaser/blob/main/main.ts

[radj307]

Related: microsoft/winget-cli#1255
Workaround: microsoft/winget-cli#1255 (comment)

[radj307]

I have identified the problem. Winget gets the current version number from the program's Uninstall key in the Registry, by checking for a property named DisplayVersion.

Volume Control's installer does not currently set this value.

The Inno setup script should be modified to set the DisplayVersion property to the installed version number, which should fix the problem.

[radj307]

Implemented a fix in d032056

Despite Inno Setup providing a few different parameters to set various values in the application uninstall key, AFAIK it does not provide a way to set the DisplayVersion value. It does, however, provide a way to set registry keys/values in general.
Since Volume Control can be installed for all users or only the current user, its registry key can be in two different places:
HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall (All Users)
HKCU\Software\Microsoft\Windows\CurrentVersion\Uninstall (Current User)

Adding PrivilegesRequired=lowest to [Setup] will install the application without admin permissions when installing for the current user. Now we can check IsAdmin to determine the installation scope, and conditionally install the registry value to the appropriate location:

[Registry]
; All Users
Root: HKLM; Subkey: "Software\Microsoft\Windows\CurrentVersion\Uninstall\{{#AppID}_is1"; ValueType: string; ValueName: "DisplayVersion"; ValueData: "{#AppVersion}"; Flags: uninsdeletevalue; Check: IsAdmin
; Current User
Root: HKCU; Subkey: "Software\Microsoft\Windows\CurrentVersion\Uninstall\{{#AppID}_is1"; ValueType: string; ValueName: "DisplayVersion"; ValueData: "{#AppVersion}"; Flags: uninsdeletevalue; Check: not IsAdmin

We'll find out whether this worked or not in the next release.

[radj307]

Due to the way that winget is set up, it just isn't possible to make new versions available very quickly.

Volume control's built-in update checker works by comparing the version number of the latest release on github to the current version. So as soon as a new release is created, volume control's update checker can see it. In order for new releases to make it to winget, a release has to be posted to github, which then triggers the workflow to create a pull request in the winget-pkgs repository. The pull request has to be reviewed by a community moderator, which can take some time.

[radj307]

The changes in d032056 did not fix the problem. The DisplayVersion registry key is created successfully, but Inno Setup immediately overrides it because it creates the uninstall key after anything set in the [Registry] section.

Related:

• https://stackoverflow.com/questions/60289363/write-custom-string-value-into-software-microsoft-windows-currentversion-uninsta
• https://stackoverflow.com/questions/25275892/restore-previously-entered-data-on-custom-page-next-time-inno-setup-made-install

[radj307]

Fixed in fb0992a