Winget should sanitize product version metadata in registry

[agowa]

Description of the new feature / enhancement

Currently we still have enough installers that fail to set their metadata properly within the registry. This causes winget to incorrectly detect the version number and suggest updating the application erroneously.
Winget should at least sanitize the most common (and easily detectable) mismatches when installing and updating a package. We cannot fix everything, but we can at least fix the generic/common ones to improve the user experience.

Proposed technical implementation details

Error cases:

• the installer wrote "" (nothing), "0.0.0", "1.0.0" or "1.0" into the registry. => The developer didn't provide any version information and the installer wrote a default value => winget should write the expected version into the registry to fix this. Write debug/info message into the log, but don't show any warning or error message.
• The Installer wrote a truncated version into the registry. e.g. "86" or "86.3" instead of "86.3.48958" or "86.3-rc1" => Most likely the installer or build script didn't preserve/support the format or length of the version number. => winget should write the expected version into the registry to fix this. Write debug/info message into the log, but don't show any warning or error message.
• The version number in the registry is prefixed with "v", but otherwise matches what we expected => winget should sanitize the version number by removing the "v" prefix and update it within the registry. Write debug/info message into the log, but don't show any warning or error message.
• All other cases will throw a warning or error (see below).

The last one can be further split into:

• The version number read from the registry is lower than what we expected => Fail the install/update. The most likely case is the installer NOOPed instead of actually doing the install/update. So we should fail instead of returning successfully.
• The version number read from the registry is higher than what we expected AND we were told to install a specific version (I.E. not latest) => The installer either silently auto updated before returning, or NOOPed because a higher version was already installed. We should throw an error.
• The version number read from the registry is higher than what we expected AND we were told to install latest => Throw a warning, most likely the installer auto updated before returning and our metadata file doesn't yet contain the latest version number.
• The version number read from the registry is just different and we cannot tell anything else (I.E. none of the above cases but also not what we expected) => Throw a version mismatch error and fail the install. Together with the above cases we can expect this to only have a minimal impact in cases where the install wasn't silently failing. (I don't know of any software installer, including enterprise, that writes e.g. "2.0" into this field while installing "3.0", if they write incorrect information it is almost always one of the initial two cases).

[stephengillie]

This seems like it might be related:

• Improve version parsing to better support "preambles" #2394

[agowa]

Somewhat, the one you liked is about parsing the version number within the registry. This one is about sanitizing it right after the installer wrote it as well as add some safeguards and error handling using it to validate that we actually updated/installed the expected application and version (and weren't fooled by the installer silently failing)

[denelon]

WinGet only writes registry entries when it acts as the installer for portable packages. There are too many expected unintended consequences if WinGet modifies the registry for things it installed vs. what the installer is doing itself.

This is essentially a policy of WinGet not to modify things it doesn't have full control over. The best suggestion I currently have is to inform the ISV (Independent Software Vendor) / publisher so they can address the installer. WinGet has become a bit of a forcing function in terms of providing a consistent experience for users and publishers to identify gaps and improvements.

I've been looking at the possibility of gathering information for the various installer types and providing a more comprehensive set of documents to help publishers understand what a "good" installer/uninstaller does/looks like and how to confirm the behaviors with WinGet to ensure the publisher can offer the best experience to their customers.

[agowa]

Ok, assuming that policy is currently non-negotiable can we add the other parts? I.E. the sanity checks. Maybe as a two stage thing, only throw warnings in all cases for now, but schedule a switch for the suggested errors in X number of releases?
That way installers over time would automatically change to write correct metadata.
(Also we could add an additional check to only throw that error for everything that was added after that date, so that installing older versions would still have the current behavior. Also for cases where packager != vendor, we could add a new option to the metadata file like setupProvidedVersionInfo: "wrongVersionString" and to discourage just using that have an ugly warning when installing it or something)

Would something like that be viable?

[denelon]

We're working towards doing these kind of checks in validation and surfacing them in the PR. I think that would be the first step. Currently, we only test a "clean install flow". Once we get these checks in place, I'd like to start looking at an upgrade flow and an uninstall flow. With the Windows Sandbox we might be able to expose this automation so publishers have an easier mechanism to test their packages with WinGet in various scenarios so they can easily observe what is happening. I've been discussing writing more centralized guidance for building and testing installer scenarios for all package installer types.