MSIX im großen Maßstab: Was 3.261 automatisierte Paketierungsfälle zeigen

Kann ein automatisierter Workflow bestehende Windows-Anwendungen in Tausenden von Fällen in MSIX-Pakete umwandeln, und nicht nur in einer Handvoll Demonstrationen? Unsere neue Studie sagt ja, für einen großen Teil der untersuchten Fälle: Von 3.261 Anwendungsfällen erzeugten 2.957 ein MSIX-Paket (90,68 %), und 2.610 verzeichneten einen vollständig bestandenen Smoke-Test (80,04 %). Das Papier "MSIX at Scale: An Automated Packaging Study of 3,261 Windows Application Cases" ist ab sofort auf Zenodo verfügbar, unter einer CC-BY-4.0-Lizenz mit dem DOI 10.5281/zenodo.21985871, zusammen mit einem Supplement, mit dem jede Zahl nachgerechnet werden kann.

Wenn Sie den Anwendungsbestand einer Organisation mit 50 bis 600 Benutzern betreuen oder als MSP Anwendungen für Kunden paketieren, kennen Sie die Frage hinter dieser Forschung. Sie haben Installer, MSI-Dateien, ZIP-Archive und portable Tools in jeder erdenklichen Form. Sie von Hand neu zu paketieren ist langsam, jeder Paketierer macht es etwas anders, und der Rückstau schrumpft selten. Die Studie fragt, ob sich diese Arbeit in großer Menge zuverlässig wiederholen lässt, und sie definiert sorgfältig, was "funktioniert" bedeutet.

Was die Studie gemessen hat

MSIX ist das Paketformat von Microsoft zum Installieren und Verwalten von Windows-Anwendungen. Ein Paket bündelt die Anwendungsdateien mit einem Manifest, das Windows mitteilt, was das Paket enthält und wie seine Anwendungen starten. Die Konvertierungsanleitung von Microsoft behandelt Vorbereitung, Aufzeichnung, Paketerstellung und Test als getrennte Schritte, und auch die Studie hält diese Schritte getrennt.

Wir haben die am 27. Juni 2026 abgeschlossenen Datensätze für jeden Fall analysiert, in dem ein MSIX-Paketierungsversuch aufgezeichnet wurde. Die Anwendungen stammen aus Suchen im öffentlichen Katalog des Windows Package Manager (WinGet). Jeder versuchte Fall zählt im Nenner, auch diejenigen, die früh abbrachen, sodass die Hauptprozentsätze nicht durch stillschweigendes Weglassen von Fehlschlägen aufgebläht werden können.

Jeder Fall wurde in vier Stufen ausgewiesen:

1. Paket erzeugt: Der MSIX-Build wurde abgeschlossen.
2. Installiert und registriert: Das Paket wurde für einen Testbenutzer installiert, und Windows hat es registriert.
3. Einstiegspunkt gestartet: Ein ausgewähltes Programm im Paket wurde gestartet.
4. Vollständig bestandener Smoke-Test: Installation, Start, Beenden und Bereinigung wurden alle als erfolgreich aufgezeichnet, ohne erkannten Absturz.

Ein Smoke-Test ist eine kurze erste Prüfung, kein vollständiger Test. Er bestätigt, dass ein Paket installiert wird, dass ein ausgewähltes Programm startet und dass der Test beendet und bereinigt wird. Er prüft weder die Anmeldung noch das Bearbeiten eines Dokuments oder das Speichern von Daten. Diese Unterscheidung haben wir im gesamten Papier sichtbar gehalten, und wir halten sie auch hier sichtbar.

Die Ergebnisse

Jeder Prozentsatz bezieht sich auf alle 3.261 versuchten Fälle. Die Stufen überschneiden sich und dürfen daher nicht addiert werden.

Achten Sie darauf, wo die Fälle wegfallen. 304 Versuche erzeugten kein Paket, aber fast ebenso viele, nämlich 281, wurden sauber installiert und registriert und verzeichneten danach keinen Programmstart. Das ist die praktische Lehre für jedes Paketierungsprogramm: Eine Paketdatei auf dem Datenträger, oder sogar eine saubere Installation, ist nicht dasselbe wie eine Anwendung, die läuft. Build-Erfolg und Anwendungserfolg müssen getrennt ausgewiesen werden, sonst sieht ein Migrationsplan gesünder aus, als er ist.

Bestandene Tests gab es außerdem bei jedem Quelltyp der Studie. Hier sind die vollständig bestandenen Smoke-Tests nach Installer- oder Verteilungstyp:

Diese Gruppen enthalten unterschiedliche Anwendungen mit unterschiedlichen Anforderungen, daher zeigt die Tabelle nicht, dass ein Installer-Typ eine höhere oder niedrigere Erfolgschance verursacht. Sie zeigt aber, dass erfolgreiche Ergebnisse nicht auf eine Art von Installer beschränkt waren. Das ist wichtig, wenn Ihr Bestand eine Mischung aus allen ist.

Wie wir die Nachweise geprüft haben

Zahlen wie diese verdienen eine genaue Prüfung, deshalb beschreibt das Papier, wie sie vor der Veröffentlichung getestet wurden.

• Jeder bestandene Test wurde mit seinem gespeicherten Bericht abgeglichen. Alle 2.610 aufgezeichneten bestandenen Smoke-Tests wurden über die sechs Teststufenfelder mit ihren verknüpften Original-Testberichten verglichen. Alle stimmten überein.
• Doppelte Berichte wurden identifiziert. Datei-Fingerabdrücke zeigten sechs Fallpaare mit identischen Berichten, daher zählt das Papier Katalogfälle und gespeicherte Ergebnisse, nicht unabhängige Testläufe.
• Wir haben den unbequemen Befund offengelegt. Zwei bestandene Fälle starteten ein Deaktivierungsprogramm statt der Hauptanwendung, und die automatisierte Identitätsprüfung hat das nicht erkannt. Nach der festgelegten Regel bleiben sie in der Summe, und das Papier nutzt sie als deutlichstes Beispiel dafür, warum ein Start kein Beweis ist, dass die beabsichtigte Anwendung funktioniert.
• Wiederholungen werden offengelegt. Die gespeicherten Verläufe enthalten 3.942 Versuchszusammenfassungen: 2.712 Fälle hatten einen Versuch, 417 zwei und 132 drei. Das sind Workflow-Ergebnisse, keine Erfolgsquoten beim ersten Versuch.

Das Supplement enthält die Ergebnisse auf Fallebene, Auswahlnotizen und Python-Skripte, die jede Tabelle und jeden Prozentsatz reproduzieren.

Was die Studie nicht behauptet

Die Grenzen sind ebenso nützlich wie die Ergebnisse, besonders wenn Sie diese Forschung mit anderen in Ihrer Organisation teilen möchten.

• Sie ist keine allgemeine Kompatibilitätsquote. Die Anwendungen wurden aus Katalogsuchen gezogen, nicht als Zufallsstichprobe, und sie repräsentieren weder Ihre Anwendungsliste noch Windows-Software im Allgemeinen.
• Sie ist kein Nachweis der Produktionsreife. Tests von Geschäftsaufgaben, langfristige Zuverlässigkeit und die Bereitstellung an Endbenutzer wurden nicht gemessen.
• Sie misst keine Zeit- oder Kosteneinsparungen. Es gab keinen Vergleich mit manueller Paketierung oder anderen Ansätzen.
• Sie wurde nicht unabhängig wiederholt. Das Papier ist ein Preprint und wurde nicht begutachtet (Peer Review). Ich entwickle EtherApps Forge, das in der Studie verwendete Tool, und habe ein kommerzielles Interesse an den Ergebnissen. Diese Beziehung ist im Papier offengelegt und sollte von allen Lesenden berücksichtigt werden.

Ein Fall ohne erfolgreiches Ergebnis ist zudem kein Beweis, dass die Anwendung nicht mit MSIX funktionieren kann. Manche Anwendungen brauchen Fix-ups, ein anderes Paketformat oder einen genaueren Blick.

Was das für Ihr Paketierungsprogramm bedeutet

Für IT-Verantwortliche und MSP-Geschäftsführer stützt die Forschung eine klare Position: MSIX ist eine praktikable Paketierungsoption für geeignete bestehende Windows-Anwendungen und gehört in Ihre Paketierungsstrategie. Es sollte nicht für jede Anwendung verpflichtend sein, und die Entscheidung trifft man am besten Anwendung für Anwendung.

Für die Fachleute, die die Arbeit erledigen, zeigt das Papier einen Entscheidungsprozess, den Sie auf Ihren eigenen Bestand anwenden können:

1. Mit den eigenen Anwendungen testen. Bewerten Sie MSIX anhand der Anwendungen, die Ihre Organisation tatsächlich nutzt, nicht anhand der Beispielliste eines Anbieters.
2. Die Stufen getrennt halten. Erfassen Sie Paketerstellung, Installation, die erste Prüfung und Tests von Geschäftsaufgaben als eigenständige Ergebnisse.
3. Bestätigen, dass das richtige Programm startet. Prüfen Sie, dass der Starttest die beabsichtigte Hauptanwendung auswählt und kein Hilfsprogramm.
4. Echte Arbeit testen. Anmeldung, Dateiverarbeitung, Integrationen, Updates und längere Nutzung, danach die Bereitstellung auf sauberen Zielgeräten.
5. Die Ausnahmen gezielt weiterleiten. Anwendungen, die Treiber, Dienste oder maschinenweite Änderungen benötigen, gehören womöglich in ein anderes Format. Der Capture-first-Weg zu MSIX für komplexe Windows-Anwendungen beschreibt, wie Sie diese Entscheidung treffen.

Denken Sie auch an das Full-Trust-Verhalten. Die Containerisierungsanleitung von Microsoft weist darauf hin, dass eine paketierte Desktop-App mit Full Trust mit denselben Berechtigungen läuft wie eine normale Desktop-App. MSIX bietet Ihnen also saubere Installation und Entfernung, aber keine automatische Sicherheitsgrenze.

Wenn Sie das Thema vor ein Change Board oder zu einem Kunden bringen müssen, liefern Ihnen der DOI und das reproduzierbare Supplement Nachweise, die Sie weiterleiten und andere prüfen können.

Wo EtherApps Forge ins Bild passt

EtherApps Forge war der Workflow, der in der gesamten Studie verwendet wurde. Es prüfte jede Quelle, erfasste die Dateien und Einstellungen der Anwendung, baute und signierte das MSIX-Paket und installierte, startete und bereinigte es anschließend als ersten Test. Das Fazit des Papiers ist bewusst zurückhaltend: EtherApps Forge kann Ihnen helfen, geeignete bestehende Anwendungsquellen in MSIX-Pakete umzuwandeln, die für Ihre eigene Validierung bereitstehen. Es ist kein Anspruch auf eine vollständig unbeaufsichtigte, produktionsreife Migration.

EtherApps Forge ist eine Windows-Desktopanwendung, die in Ihrer eigenen Umgebung läuft, sodass Aufzeichnungen und Pakete bei Ihnen bleiben. Sein Workflow für agentische Anwendungspaketierung empfiehlt einen Weg auf Basis des tatsächlichen Anwendungs-Footprints, und seine Package Support Framework-Fix-ups helfen erfassten Anwendungen, die eine Datei- oder Registrierungsumleitung benötigen. Für Bestände mit über Jahre angesammelten Installern deckt Modernisierung von Legacy-Anwendungen Erkennung und Behebung ab. Frühere Papiere aus demselben Forschungsprogramm betrachten natives MSIX im Vergleich zu App Attach für Azure Virtual Desktop und wo das Package Support Framework das Risiko bei MSIX und App Attach erhöht.

Der schnellste Weg, um zu sehen, ob sich Ihre eigenen Anwendungen wie die Fälle in der Studie verhalten, ist, sie durch denselben Workflow laufen zu lassen. EtherApps Forge enthält eine kostenlose 7-tägige Testversion des vollständigen Workflows, und jede Lizenz umfasst Schulung und Support.

MSIX-Paketierung und -Bereitstellung entdecken, um zu sehen, wie aus den vierstufigen Nachweisen der Studie ein wiederholbarer Paketierungs- und Bereitstellungsprozess für Ihren Bestand wird.