As stated in the issue, the issue is not the WinGet packages; the LINQ application's neither v5 nor v6, reporting it to the Windows Add/Remove Programs registry properly. (I'm not sure if that is the correct statement, I'm just relaying the info there to here, as a fan of LINQPad)
Since WinGet is now officially a way of Microsoft's Windows application distribution, I feel like you need to step in.
As far as I can see here, all the settings are correct. There is no way that the maintainer can do anything about it.
If LINQPad populated the registry version key in HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall, it would need to update the key (requiring administrative elevation) each time it performed an automatic update. However, LINQPad is able to update itself without administrative elevation - it writes the new files to %localappdata% and runs the updated version from there. Patching the original executable and DLL files in %programfiles% is a bonus (to improve startup time very slightly) which it attempts only if administrative elevation is granted.
I'm not sure whether it's better to have no version info, or version info that may be outdated or misleading.
My 2 cents goes to reporting outdated or misleading info.
The reason I think that will be better because at that point, it will report WinGet a version number, and users can upgrade it if they want to ensure the version is the latest and the greatest. Even they already have the latest version.
The alternative continues update upon command winget upgrade --all.
Comments
As stated in the issue, the issue is not the WinGet packages; the LINQ application's neither v5 nor v6, reporting it to the Windows Add/Remove Programs registry properly. (I'm not sure if that is the correct statement, I'm just relaying the info there to here, as a fan of LINQPad)
Since WinGet is now officially a way of Microsoft's Windows application distribution, I feel like you need to step in.
As far as I can see here, all the settings are correct. There is no way that the maintainer can do anything about it.
If LINQPad populated the registry version key in HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall, it would need to update the key (requiring administrative elevation) each time it performed an automatic update. However, LINQPad is able to update itself without administrative elevation - it writes the new files to %localappdata% and runs the updated version from there. Patching the original executable and DLL files in %programfiles% is a bonus (to improve startup time very slightly) which it attempts only if administrative elevation is granted.
I'm not sure whether it's better to have no version info, or version info that may be outdated or misleading.
My 2 cents goes to reporting outdated or misleading info.
The reason I think that will be better because at that point, it will report WinGet a version number, and users can upgrade it if they want to ensure the version is the latest and the greatest. Even they already have the latest version.
The alternative continues update upon command
winget upgrade --all.Fair point.
I'll put the ProductVersion into the upcoming 6.14 RTM setup. The auto-updater will start attempting to patch it from 6.15.x.
I appreciate it if you may do the same thing for v5 too. Many thanks for considering my request.