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]

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.

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]

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.

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

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

@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]

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

@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]

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

@riverar, have you read https://github.com/microsoft/winget-cli/issues/4711#issuecomment-2273974960? 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. ^1 If of interest, consider correcting it, if you happen to know.

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

[RokeJulianLockhart]

This affects https://github.com/microsoft/WinDbg-Feedback/issues/91#issuecomment-1633383312.

[riverar]

Right, ingesting .appinstaller as-is is probably never going to happen and doesn't really make sense. Perhaps there's some value in adding .appinstaller support as a dev feature that allows developers to import .appinstaller and export a native winget manifest for commit to the winget-pkgs repository.

This issue lacks a documented motivation; @RokeJulianLockhart can you make edits/elaborate what you're trying to do and why you need this?

[RokeJulianLockhart]

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

@riverar, I've encountered multiple important applications that are solely distributed with .AppInstaller installation files (notably, "Files" and WinDbg). In discussions with their developers, I've yet to see .MSIX or .MSIXBundle be considered to be desirable alternatives, but I want these to be acquirable via WinGet.

[riverar]

@RokeJulianLockhart Just to make sure we're on the same page, an .appinstaller file is a simple XML file that points to an existing msix/appx bundle and describes dependencies, update behavior, etc.

Here's a real example:

<?xml version="1.0" encoding="utf-8"?>
<AppInstaller xmlns="http://schemas.microsoft.com/appx/appinstaller/2017/2" Uri="https://install.eartrumpet.app/dev/EarTrumpet.Package.appinstaller" Version="2.3.0.99">
  <MainBundle Name="40459File-New-Project.EarTrumpet" Version="2.3.0.99" Publisher="CN=File-New-Project, O=File-New-Project, L=Purcellville, S=Virginia, C=US" Uri="https://install.eartrumpet.app/dev/EarTrumpet.Package_2.3.0.99_x86_x64_arm64.msixbundle" />
  <Dependencies>
    <Package Name="Microsoft.VCLibs.140.00.UWPDesktop" Publisher="CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US" Version="14.0.30704.0" ProcessorArchitecture="x86" Uri="https://aka.ms/Microsoft.VCLibs.x86.14.00.Desktop.appx" />
    <Package Name="Microsoft.VCLibs.140.00.UWPDesktop" Publisher="CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US" Version="14.0.30704.0" ProcessorArchitecture="x64" Uri="https://aka.ms/Microsoft.VCLibs.x64.14.00.Desktop.appx" />
    <Package Name="Microsoft.VCLibs.140.00.UWPDesktop" Publisher="CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US" Version="14.0.30704.0" ProcessorArchitecture="arm64" Uri="https://aka.ms/Microsoft.VCLibs.arm64.14.00.Desktop.appx" />
  </Dependencies>
  <UpdateSettings>
    <OnLaunch HoursBetweenUpdateChecks="0" />
  </UpdateSettings>
</AppInstaller>

[RokeJulianLockhart]

@riverar, thanks! That makes manually extracting the package URI possible:

windbg.appinstaller

<?xml version="1.0" encoding="utf-8"?>
<AppInstaller Uri="https://windbg.download.prss.microsoft.com/dbazure/prod/1-0-0/windbg.appinstaller" Version="1.2504.15001.0" xmlns="http://schemas.microsoft.com/appx/appinstaller/2018">
  <MainBundle Name="Microsoft.WinDbg" Version="1.2504.15001.0" Publisher="CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US" Uri="https://windbg.download.prss.microsoft.com/dbazure/prod/1-2504-15001-0/windbg.msixbundle" />
  <UpdateSettings>
    <OnLaunch HoursBetweenUpdateChecks="0"/>
    <AutomaticBackgroundTask/>
    <ForceUpdateFromAnyVersion>true</ForceUpdateFromAnyVersion>
  </UpdateSettings>
</AppInstaller>

However, acquiring later versions of the URIs to the MSIX packages isn't a simple endeaviour, for .. returns, as merely one example:

GatewayExceptionResponse

Consequently, being able to poll the stable download URI for the .AppInstaller, and parsing the standardised XML to acquire the unstable URI of the MSIX package, makes this automatable.