Verify installed version matches upgrade target after installer success

[AMDphreak]

Summary

Follow-up to misleading success output when an upgrade exits 0 but Windows still reports an older installed version (see #4550 and related reports).

Behavior

After a successful installer return code, if the operation is an upgrade (InstallerExecutionUseUpdate):

• ARP path: After ARP correlation finds the installed package, compare Utility::Version of the correlated installed version to the manifest package version. If the installed version sorts less than the expected (manifest) version, fail with APPINSTALLER_CLI_ERROR_UPGRADE_INSTALLED_VERSION_MISMATCH (0x8A15008F).
• MSIX path: When the manifest provides a package family name and the package is registered, compare using Deployment::GetInstalledVersionStringForFamilyName where applicable.
• Skip verification when reboot is required to finish, when versions are unknown, or when correlation does not yield a reliable installed version string.

Notes

Portable/zip flows that do not correlate to ARP/MSIX are unchanged.

Testing

CI / AppInstallerCLITests as usual.

Made with Cursor

Microsoft Reviewers: Open in CodeFlow

[JohnMcPMS]

Two things:

1. Building another PR on top of the changes in the first makes reviewing it independently difficult. Please create a new branch for each change off of the mainline. Yes, if you are adding errors you are very likely to create a conflict with yourself.
2. I don't know that we can take this change with it producing an error. Some installers are not well behaved and will not update the installed version number in an update. Those usually get tagged in the manifest to prevent repeated upgrades, but I don't want to start treating updates to them as failures. I would be more accepting of a warning message that indicates that the upgrade did this, but if the process produces success we have to treat it as such.

[Trenly]

I don't know that we can take this change with it producing an error. Some installers are not well behaved and will not update the installed version number in an update. Those usually get tagged in the manifest to prevent repeated upgrades, but I don't want to start treating updates to them as failures. I would be more accepting of a warning message that indicates that the upgrade did this, but if the process produces success we have to treat it as such.

I appreciate you callimg this out - The community repository just surpassed 12,000 packages that are available which means that any changes to reporting an error here would be breaking in my opinion; especially when you consider the automations and integrations enterprises and independent developers have built around the existing behavior of the CLI.