microsoft
WinGet does not correlate non-MSIX installer installations of an MSIX application
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 https://github.com/microsoft/winget-cli/pull/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
- Install
Microsoft.WSLorMicrosoft.WindowsRuntime.1.x - 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
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
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.
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
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.
With 2.6.0 public I am betting the pressure will be on to figure out the correlation between the installs and the manifests so any leads on bridging the issue?
I can have some folks use wsl --update to self-manage, but requires elevated perms that usually Intune provides (republished Store app in Company Portal orchestrating winget) so trying to figure out if i need to load the MSIs into a custom package for the near term when 2.6.0 gets tagged release. I am also guessing appinst will need a version bump as well if the schema changes so the resolution may be a ways out before I could deploy it in prod.
@craigloewen-msft are you hearing of any progress on getting WSL in a place where winget can do proper reconciliation or winget handling this particular case?
Had a supplier throw me a curveball where they started requiring a more recent version of WSL than I had packaged so been chasing incidents all day to get folks updated (most do not have admin so running wsl --update isn't an option).
@byjrack to do that, we would need a feature in WinGet that WSL would need to consume. So I think the ask here is on the WinGet team as Demitrius mentioned above.
Yeah @craigloewen-msft i am on the same page. Wasn't sure if there was the possibility for WSL to stay all MSI. Now may not work anyways cause the past fingerprint is still MSIX. Or if you had heard about anything from the winget team that might get things unblocked.
I think we could go through and delete all traces of MSIX from WinGet from the past WSL packages which might solve this.
@denelon would that work???