Support the `.AppInstaller` file format.

[RokeJulianLockhart]

Description of the new feature / enhancement

1. Request

   As winget-pkgs/issues/166364#issuecomment-2273528233 explains (paraphrased):

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

2. Prerequisites

   1. Reported here, rather than at winget-pkgs, per winget-pkgs/issues/174#issuecomment-629701649.

   2. issues?q=sort%3Aupdated-desc+is%3Aissue+appinstaller+support returned 0 duplicate results on 2024-08-07.

Proposed technical implementation details

Per #issuecomment-2885088781, parse the XML to acquire the URI of the linked MSIX package.

[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 ↩