Support the `.AppInstaller` file format.

[RokeJulianLockhart]

Description of the new feature / enhancement

Request

As https://github.com/microsoft/winget-pkgs/issues/166364#issuecomment-2273528233 explains (paraphrased):

*.appinstaller [...] is currently not supported by winget.exe, since it can't be installed unattendedly.

Prerequisites

1. Reported here, rather than at winget-pkgs, per https://github.com/microsoft/winget-pkgs/issues/174#issuecomment-629701649.
2. https://github.com/microsoft/winget-pkgs/issues?q=sort%3Aupdated-desc+is%3Aissue+appinstaller+support returned 0 duplicate results at 2024-08-07.

Proposed technical implementation details

No response

[stephengillie]

This does seem like the next step on a path of supporting installing all types of packages, especially after adding WindowsFeatures support. And along that line, what happens if another package depends on an .AppInstaller package, to install or run?

[denelon]

The ".appinstaller" extension is just remnants of earlier iterations of the "MSIX" package format.

[RokeJulianLockhart]

https://github.com/microsoft/winget-cli/issues/4711#issuecomment-2273894219

@denelon, considering your position, I do really want to accept that, but https://github.com/microsoft/winget-pkgs/issues/166364#issuecomment-2273966067 appears to rather verbosely explain otherwise:

2. I did ask How do APPX, MSIX/MSIXBundle, and AppInstaller packages differ? at SE SU prior to filing this, but I didn't receive any responses, so I wasn't aware.

@RokeJulianLockhart,

.appx and .msix are basically the same. You can change the extension from one to the other and things will generally work. Difference is that .appx is older. Older versions of the OS don't know MSIX (I think those are already out of support), and there are probably features that are only supported in MSIX and not APPX, but the package format is the same.

A bundle (either MSIX or APPX) contains a collection of individual packages. Those can be variations of the same package, just for different architectures. Or they can be resource packages with the strings/assets for different locales.

A .appinstaller file is an XML file that helps the OS manage auto-updates and dependencies for an MSIX package/bundle. It lists a URI for a main package and its dependencies, so that the OS can install the dependencies before the main package. It also lists a URI where a new version of the .appinstaller file can be found, and the OS can use that to check for updates.

Without changes to winget, you can already add a package for which you have a .appinstaller by just opening it in a text editor and extracting the package URI to use in winget.

*.appinstaller of this package is currently not supported by winget.exe, since it can't be installed unattendedly

@Dragon1573, It isn't true that it cannot be installed unattended (but it's true that winget doesn't support it). You can do Add-AppPackage -AppInstallerFile <path> in PowerShell, or use the API PackageManager.AddPackageByUriAsync()

Irrespective, does such a designation as what you state impact this request?

[denelon]

We would need to evaluate the logic necessary to take .appinstaller files and extract the metadata to make it easier to submit. It might be a case where we could do something in the pipelines or offer a mechanism to more easily extract the necessary information.

Is this blocking an important package for your scenario or a collection of packages?

[RokeJulianLockhart]

https://github.com/microsoft/winget-cli/issues/4711#issuecomment-2274350381

@denelon, I consider https://github.com/files-community/Files to be important, but luckily, in this case, another developer has provided MSIX packages for WinGet specifically, so it's not blocking anything of mine anymore (thus far).

However, it does appear to block https://github.com/microsoft/winget-pkgs/pull/29790#issuecomment-938400795.