WinGet does not correlate non-MSIX installer installations of an MSIX application

[mdanish-kh]

Brief description of your issue

The title is a bit weird, but I'm referring to MSI / EXE or any other installer technology that actually install an MSIX package. Examples I know in the WinGet repo being Microsoft.WSL (MSI installer installing the MSIX) & Microsoft.WindowsRuntime.1.x (EXE installer installing the MSIX). Both of these are not correlated correctly by WinGet.

~ winget list linux
Name                        Id                                                                               Version     Source
--------------------------------------------------------------------------------------------------------------------------------
Ubuntu                      Canonical.Ubuntu                                                                 2404.1.68.0 winget
Ubuntu 24.04.1 LTS          Canonical.Ubuntu.2404                                                            2404.1.26.0 winget
Windows Subsystem for Linux MSIX\MicrosoftCorporationII.WindowsSubsystemForLinux_2.4.13.0_x64__8wekyb3d8bbwe 2.4.13.0

 ~ winget list WindowsAppRuntime
Name                        Id                                                                         Version          Available Source
----------------------------------------------------------------------------------------------------------------------------------------
WindowsAppRuntime.Singleton MSIX\Microsoft.WindowsAppRuntime.Singleton_3.469.1654.0_x64__8wekyb3d8bbwe 3.469.1654.0
WindowsAppRuntime.1.0       MSIX\Microsoft.WindowsAppRuntime.1.0_4.528.1755.0_x86__8wekyb3d8bbwe       4.528.1755.0
WindowsAppRuntime.1.0       MSIX\Microsoft.WindowsAppRuntime.1.0_4.528.1755.0_x64__8wekyb3d8bbwe       4.528.1755.0
WindowsAppRuntime.1.2       MSIX\Microsoft.WindowsAppRuntime.1.2_2000.802.31.0_x64__8wekyb3d8bbwe      2000.802.31.0
WindowsAppRuntime.1.2       MSIX\Microsoft.WindowsAppRuntime.1.2_2000.802.31.0_x86__8wekyb3d8bbwe      2000.802.31.0
WindowsAppRuntime.1.3       MSIX\Microsoft.WindowsAppRuntime.1.3_3000.851.1712.0_x64__8wekyb3d8bbwe    3000.851.1712.0
WindowsAppRuntime.1.3       MSIX\Microsoft.WindowsAppRuntime.1.3_3000.882.2207.0_x64__8wekyb3d8bbwe    3000.882.2207.0
WindowsAppRuntime.1.3       MSIX\Microsoft.WindowsAppRuntime.1.3_3000.934.1904.0_x86__8wekyb3d8bbwe    3000.934.1904.0
WindowsAppRuntime.1.3       MSIX\Microsoft.WindowsAppRuntime.1.3_3000.934.1904.0_x64__8wekyb3d8bbwe    3000.934.1904.0
WindowsAppRuntime.1.1       MSIX\Microsoft.WindowsAppRuntime.1.1_1005.616.1651.0_x86__8wekyb3d8bbwe    1005.616.1651.0
WindowsAppRuntime.1.1       MSIX\Microsoft.WindowsAppRuntime.1.1_1005.616.1651.0_x64__8wekyb3d8bbwe    1005.616.1651.0
WindowsAppRuntime.1.5       MSIX\Microsoft.WindowsAppRuntime.1.5_5001.119.156.0_x64__8wekyb3d8bbwe     5001.119.156.0
WindowsAppRuntime.1.4       MSIX\Microsoft.WindowsAppRuntime.1.4_4000.1227.1637.0_x64__8wekyb3d8bbwe   4000.1227.1637.0
WindowsAppRuntime.1.5       MSIX\Microsoft.WindowsAppRuntime.1.5_5001.159.55.0_x64__8wekyb3d8bbwe      5001.159.55.0
WindowsAppRuntime.1.5       MSIX\Microsoft.WindowsAppRuntime.1.5_5001.178.1908.0_x64__8wekyb3d8bbwe    5001.178.1908.0
WindowsAppRuntime.1.5       MSIX\Microsoft.WindowsAppRuntime.1.5_5001.214.1843.0_x64__8wekyb3d8bbwe    5001.214.1843.0
WindowsAppRuntime.1.4       MSIX\Microsoft.WindowsAppRuntime.1.4_4000.1309.2056.0_x64__8wekyb3d8bbwe   4000.1309.2056.0
WindowsAppRuntime.1.4       MSIX\Microsoft.WindowsAppRuntime.1.4_4000.1309.2056.0_x86__8wekyb3d8bbwe   4000.1309.2056.0
WindowsAppRuntime.1.5       MSIX\Microsoft.WindowsAppRuntime.1.5_5001.275.500.0_x64__8wekyb3d8bbwe     5001.275.500.0
WindowsAppRuntime.1.5       MSIX\Microsoft.WindowsAppRuntime.1.5_5001.311.2039.0_x64__8wekyb3d8bbwe    5001.311.2039.0
WindowsAppRuntime.1.5       MSIX\Microsoft.WindowsAppRuntime.1.5_5001.373.1736.0_x64__8wekyb3d8bbwe    5001.373.1736.0
WindowsAppRuntime.1.5       MSIX\Microsoft.WindowsAppRuntime.1.5_5001.373.1736.0_x86__8wekyb3d8bbwe    5001.373.1736.0
WindowsAppRuntime.1.6       MSIX\Microsoft.WindowsAppRuntime.1.6_6000.401.2352.0_x64__8wekyb3d8bbwe    6000.401.2352.0
WindowsAppRuntime.1.6       MSIX\Microsoft.WindowsAppRuntime.1.6_6000.424.1611.0_x64__8wekyb3d8bbwe    6000.424.1611.0
WindowsAppRuntime.1.6       MSIX\Microsoft.WindowsAppRuntime.1.6_6000.457.2140.0_x86__8wekyb3d8bbwe    6000.457.2140.0
WindowsAppRuntime.1.6       MSIX\Microsoft.WindowsAppRuntime.1.6_6000.457.2140.0_x64__8wekyb3d8bbwe    6000.457.2140.0
WindowsAppRuntime.1.6       MSIX\Microsoft.WindowsAppRuntime.1.6_6000.486.517.0_x64__8wekyb3d8bbwe     6000.486.517.0
WindowsAppRuntime.1.6       MSIX\Microsoft.WindowsAppRuntime.1.6_6000.486.517.0_x86__8wekyb3d8bbwe     6000.486.517.0
WindowsAppRuntime.1.7       MSIX\Microsoft.WindowsAppRuntime.1.7_7000.498.2246.0_x86__8wekyb3d8bbwe    7000.498.2246.0
WindowsAppRuntime.1.7       MSIX\Microsoft.WindowsAppRuntime.1.7_7000.498.2246.0_x64__8wekyb3d8bbwe    7000.498.2246.0

---

After PR #3391, the recommendation for these packages seemed to be to define the PackageFamilyName in the manifest and with that WinGet would not attempt the ARP correlation (which wouldn't be applicable since the MSIX don't write to ARP). The manifests for both of these packages does contain the correct PackageFamilyName yet the correlation fails

Steps to reproduce

1. Install Microsoft.WSL or Microsoft.WindowsRuntime.1.x
2. Do winget list

Expected behavior

The correlation succeeds with installed package mapped to the PackageId from winget source

Actual behavior

Correlation fails

Environment

Windows Package Manager (Preview) v1.11.320-preview
Copyright (c) Microsoft Corporation. All rights reserved.

Windows: Windows.Desktop v10.0.26100.4061
System Architecture: X64
Package: Microsoft.DesktopAppInstaller v1.26.320.0

Winget Directories
-------------------------------------------------------------------------------------------------------------------------------
Logs                               %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\DiagOutputDir
User Settings                      %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\settings.json
Portable Links Directory (User)    %LOCALAPPDATA%\Microsoft\WinGet\Links
Portable Links Directory (Machine) C:\Program Files\WinGet\Links
Portable Package Root (User)       %LOCALAPPDATA%\Microsoft\WinGet\Packages
Portable Package Root              C:\Program Files\WinGet\Packages
Portable Package Root (x86)        C:\Program Files (x86)\WinGet\Packages
Installer Downloads                %USERPROFILE%\Downloads
Configuration Modules              %LOCALAPPDATA%\Microsoft\WinGet\Configuration\Modules

Links
---------------------------------------------------------------------------
Privacy Statement   https://aka.ms/winget-privacy
License Agreement   https://aka.ms/winget-license
Third Party Notices https://aka.ms/winget-3rdPartyNotice
Homepage            https://aka.ms/winget
Windows Store Terms https://www.microsoft.com/en-us/storedocs/terms-of-sale

Admin Setting                             State
--------------------------------------------------
LocalManifestFiles                        Enabled
BypassCertificatePinningForMicrosoftStore Enabled
InstallerHashOverride                     Enabled
LocalArchiveMalwareScanOverride           Disabled
ProxyCommandLineOptions                   Disabled
DefaultProxy                              Disabled

[mdanish-kh]

It appears that the PackageFamilyNames for these applications are not populated in index.db, which means the search for PackageFamilyName fails in the installed package to available package correlation

[denelon]

Yeah, this seems to be a challenge for a few packages. They have an "MSIX", but they want the WinGet installer type to default to something else.

In theory, we could add some kind of "preferredInstallerType" thing to the schema so the manifest could default to an MSI for example, but it could still logically correlate to an installed MSIX (as in the WSL example above). Then it would be reasonable for WinGet to be able to correlate to that package type and in an "upgrade" scenario, it could select the currently installed MSIX variant of the package.

I don't know what that means when I have both the MSI and the MSIX variations of a particular package installed so there may need to be some more thought/discussion on that front.

[mdanish-kh]

In theory, we could add some kind of "preferredInstallerType" thing to the schema so the manifest could default to an MSI for example, but it could still logically correlate to an installed MSIX (as in the WSL example above). Then it would be reasonable for WinGet to be able to correlate to that package type and in an "upgrade" scenario, it could select the currently installed MSIX variant of the package.

I thought that's what AppsAndFeaturesEntries > InstallerType was there for to help with the installer selection, as it does currently with many other Win32 apps where an installer installs a different technology application. In the case of the WSL, it's defined in the manifest:

https://github.com/microsoft/winget-pkgs/blob/f58bde083cf416567912f8b4510b6c66a5204bdb/manifests/m/Microsoft/WSL/2.5.7/Microsoft.WSL.installer.yaml#L11-L12

We define InstallerType: msi (i.e. the installer), but the installed application is an MSIX. The internal application WinGet needs to match for is defined by AppsAndFeaturesEntries > InstallerType: msix and this should help with installer selection in the upgrade flow?

I would rather see this approach work as it does currently for Win32 apps rather than introducing a new manifest field for consistency

Currently, winget doesn't detect WSL as available from any source, which I think is a different issue from installer selection that will come later

[mdanish-kh]

(or maybe I'm interpreting the issue completely incorrectly :D)

[denelon]

The challenge is we don't have the package family name in the manifest. When we add the "MSIX" installer type to add that metadata, the package defaults to MSIX. I'm not sure if there is a good way "yet" to add the MSIX metadata without the installer which is why I was thinking about the additional property, so we get the desired behavior and have the necessary metadata for correlation.