Support the .AppInstaller file format.

[RokeJulianLockhart]

Description of the new feature / enhancement

Request

As microsoft/winget-pkgs#166364 (comment) 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 winget-cli .zip files not supported winget-pkgs#174 (comment).
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]

#4711 (comment)

@denelon, considering your position, I do really want to accept that, but microsoft/winget-pkgs#166364 (comment) 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.

An .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]

#4711 (comment)

@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 microsoft/winget-pkgs#29790 (comment).

[riverar]

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

No that's not right at all. Check out the docs for more information.

[RokeJulianLockhart]

#4711 (comment)

@riverar, how does your citation contradict the aforequoted? I was of the same opinion as @denelon.

[riverar]

Maybe I misunderstood, but it seemed he was suggesting AppInstaller was some sort of legacy remnant. It's a valid and active method of distributing apps (mine included).

[RokeJulianLockhart]

#4711 (comment)

@riverar, in that case, do .AppInstaller files differ to .AppX files? If so, I presume you would agree that .AppX is the predecessor to .MSIX, superceded by it?

[riverar]

Appx and Msix are essentially the same. (Appx was renamed to Msix for legal reasons.) AppInstaller refers to several things, including a manifest format (i.e., .appinstaller) used by the AppInstaller app for distributing apps outside the store.

[RokeJulianLockhart]

#4711 (comment)

@riverar, have you read #4711 (comment)? It states:

An .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.

Does this mean that it contains an MSIX package, but also adds associated update repository and dependency metadata, like an .RPM or .Deb file does?

I've tried to summarise this at superuser.com/a/1851577/904401, but I'm uncertain whether it's whatsoever accurate. ¹ If of interest, consider correcting it, if you happen to know.

Footnotes

1. superuser.com/revisions/1851577/3 ↩

[florelis]

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

I'm assuming @denelon got .appinstaller confused with .appx? AFAIK .appinstaller is still alive

---

It would be nice if winget supported .appinstaller files. Implementing the installation and detection doesn't seem that hard to do since it is mostly the same as any other MSIX. The main issue I can think of is in validation and reasoning about versions.

Packages that use .appinstaller will probably have the same issues as any app with evergreen installer URIs, in that there is only one version available at any given time and existing manifests may start pointing to newer versions.

Hash validation of the installer would probably need to follow the URIs in the XML to the actual MSIX package if we want it to be worth anything. But then we would have to download the MSIX to compute its hash, without being able to use the download for the actual installation.
The validation pipelines will also probably need to be enlightened to download the package and its dependencies for scanning.
Both of these require parsing the .appinstaller file, which is additional work to do.