MSIX op schaal: wat 3.261 geautomatiseerde packagingcases ons vertellen

Kan een geautomatiseerde workflow bestaande Windows-applicaties omzetten in MSIX-pakketten over duizenden cases, en niet alleen in een handvol demonstraties? Ons nieuwe onderzoek zegt ja voor een groot deel van de cases die we hebben geprobeerd: van 3.261 applicatiecases leverden er 2.957 een MSIX-pakket op (90,68%) en registreerden er 2.610 een volledig geslaagde smoke test (80,04%). Het paper, "MSIX at Scale: An Automated Packaging Study of 3,261 Windows Application Cases", is nu beschikbaar op Zenodo onder een CC BY 4.0-licentie met de DOI 10.5281/zenodo.21985871, samen met een supplement waarmee iedereen elk cijfer kan narekenen.

Beheert u een applicatielandschap voor een organisatie met 50 tot 600 gebruikers, of verpakt u als MSP applicaties voor klanten, dan is de vraag achter dit onderzoek u bekend. U hebt installers, MSI-bestanden, ZIP-archieven en portable tools in alle denkbare vormen. Ze handmatig herverpakken gaat traag, elke packager doet het net iets anders en de achterstand slinkt zelden. Het onderzoek vraagt of dat werk betrouwbaar en op volume herhaald kan worden, en is zorgvuldig in wat "werkte" betekent.

Wat het onderzoek heeft gemeten

MSIX is de pakketindeling van Microsoft voor het installeren en beheren van Windows-applicaties. Een pakket brengt de applicatiebestanden samen met een manifest dat Windows vertelt wat het pakket bevat en hoe de applicaties ervan starten. De conversierichtlijnen van Microsoft behandelen voorbereiding, vastlegging, pakketcreatie en testen als afzonderlijke stappen, en het onderzoek houdt die stappen ook gescheiden.

We analyseerden records, afgerond op 27 juni 2026, voor elke case waarin een MSIX-packagingpoging was vastgelegd. De applicaties kwamen uit zoekopdrachten in de openbare catalogus van Windows Package Manager (WinGet). Elke geprobeerde case telt mee in de noemer, ook de cases die vroegtijdig stopten, zodat de hoofdpercentages niet kunnen worden opgeblazen door mislukkingen stilletjes weg te laten.

Elke case werd in vier fasen gerapporteerd:

1. Pakket gemaakt: de MSIX-build is voltooid.
2. Geïnstalleerd en geregistreerd: het pakket werd geïnstalleerd voor een testgebruiker en Windows registreerde het.
3. Startpunt gestart: een geselecteerd programma in het pakket werd gestart.
4. Volledig geslaagde smoke test: installatie, starten, afsluiten en opruimen werden allemaal als geslaagd geregistreerd, zonder gedetecteerde crash.

Een smoke test is een korte eerste controle, geen volledige test. Hij bevestigt dat een pakket installeert, dat een geselecteerd programma start en dat de test afsluit en opruimt. Hij test niet het aanmelden, het bewerken van een document of het opslaan van gegevens. We hebben dat onderscheid in het hele paper zichtbaar gehouden, en dat doen we hier ook.

De resultaten

Elk percentage gebruikt alle 3.261 geprobeerde cases. De fasen overlappen elkaar, dus ze mogen niet bij elkaar worden opgeteld.

Kijk waar de cases afvallen. 304 pogingen leverden geen pakket op, maar bijna evenveel, 281, installeerden en registreerden probleemloos en registreerden daarna geen startend programma. Dat is de praktische les voor elk packagingprogramma: een pakketbestand op schijf, of zelfs een pakket dat probleemloos installeert, is niet hetzelfde als een applicatie die draait. Buildsucces en applicatiesucces moeten afzonderlijk worden gerapporteerd, anders ziet een migratieplan er gezonder uit dan het is.

Geslaagde resultaten kwamen ook uit elk brontype in het onderzoek. Hier zijn de volledig geslaagde smoke tests per installer- of distributietype:

Deze groepen bevatten verschillende applicaties met verschillende vereisten, dus de tabel toont niet aan dat een installertype een hogere of lagere slagingskans veroorzaakt. Wat de tabel wel laat zien, is dat geslaagde resultaten niet beperkt bleven tot één soort installer. Dat is van belang als uw landschap uit een mix van al deze typen bestaat.

Hoe we het bewijs hebben gecontroleerd

Cijfers als deze verdienen een kritische blik, dus het paper beschrijft hoe ze werden getoetst voordat we ze publiceerden.

• Elke geslaagde test werd gecontroleerd tegen het opgeslagen rapport. Alle 2.610 geregistreerde geslaagde smoke tests werden vergeleken met hun gekoppelde oorspronkelijke testrapporten over de zes velden van de testfasen. Ze kwamen allemaal overeen.
• Dubbele rapporten werden geïdentificeerd. Bestandsvingerafdrukken toonden zes paren cases met identieke rapporten, dus het paper telt catalogus-cases en opgeslagen resultaten, geen onafhankelijke testruns.
• We rapporteerden de ongemakkelijke bevinding. Twee geslaagde cases startten een deactiveringshulpprogramma in plaats van de hoofdapplicatie, en de geautomatiseerde identiteitscontrole signaleerde dat niet. Ze blijven volgens de vermelde regel in het totaal, en het paper gebruikt ze als het duidelijkste voorbeeld van waarom een start geen bewijs is dat de bedoelde applicatie werkt.
• Herhaalpogingen worden vermeld. De opgeslagen geschiedenissen bevatten 3.942 samenvattingen van pogingen: 2.712 cases hadden één poging, 417 hadden er twee en 132 hadden er drie. Dit zijn workflowresultaten, geen slagingspercentages bij de eerste poging.

Het supplement bevat de resultaten per case, selectienotities en Python-scripts die elke tabel en elk percentage reproduceren.

Wat het onderzoek niet beweert

De beperkingen zijn net zo nuttig als de resultaten, vooral als u van plan bent dit onderzoek met anderen in uw organisatie te delen.

• Het is geen algemeen compatibiliteitspercentage. De applicaties zijn afkomstig uit zoekopdrachten in de catalogus, niet uit een willekeurige steekproef, en ze zijn niet representatief voor uw applicatielijst of voor Windows-software in het algemeen.
• Het is geen bewijs van productiegereedheid. Het testen van bedrijfstaken, betrouwbaarheid op lange termijn en uitrol naar eindgebruikers zijn niet gemeten.
• Het meet geen tijd- of kostenbesparing. Er is geen vergelijking gemaakt met handmatige packaging of andere benaderingen.
• Het is niet onafhankelijk herhaald. Het paper is een preprint en is niet peer-reviewed. Ik ontwikkel EtherApps Forge, de tool die in het onderzoek is gebruikt, en heb een commercieel belang bij de resultaten. Die relatie is in het paper vermeld en zou door elke lezer moeten worden meegewogen.

Een case zonder geslaagd resultaat is evenmin bewijs dat de applicatie niet met MSIX kan werken. Sommige applicaties hebben fix-ups nodig, een andere pakketindeling of een nadere blik.

Wat dit betekent voor uw packagingprogramma

Voor IT-leiders en MSP-eigenaren ondersteunt het onderzoek een duidelijk standpunt: MSIX is een praktische packagingoptie voor geschikte bestaande Windows-applicaties, en het hoort in uw packagingstrategie thuis. Het zou niet verplicht moeten zijn voor elke applicatie, en de beslissing kunt u het best per applicatie nemen.

Voor de specialisten die het werk doen, wijst het paper op een beslisproces dat u op uw eigen landschap kunt toepassen:

1. Test met uw eigen applicaties. Evalueer MSIX op de applicaties die uw organisatie daadwerkelijk gebruikt, niet op de voorbeeldlijst van een leverancier.
2. Houd de fasen gescheiden. Leg pakketcreatie, installatie, de eerste controle en het testen van bedrijfstaken vast als afzonderlijke resultaten.
3. Controleer of het juiste programma start. Ga na of de starttest de bedoelde hoofdapplicatie selecteert, niet een hulpprogramma of utility.
4. Test echt werk. Aanmelden, bestandsverwerking, integraties, updates en langer gebruik, en daarna uitrol op schone doelapparaten.
5. Leid de uitzonderingen om. Applicaties die drivers, services of computerbrede wijzigingen nodig hebben, horen mogelijk in een andere indeling thuis. Het capture-first-pad naar MSIX voor complexe Windows-applicaties beschrijft hoe u die keuze maakt.

Houd ook rekening met full-trust-gedrag. De containerisatierichtlijnen van Microsoft vermelden dat een verpakte full-trust-desktopapp met dezelfde machtigingen draait als een standaard desktopapp, dus MSIX biedt u schone installatie en verwijdering, geen automatische beveiligingsgrens.

Moet u dit voorleggen aan een change board of een klant, dan geven de DOI en het reproduceerbare supplement u bewijs dat u kunt doorsturen en dat anderen kunnen controleren.

De rol van EtherApps Forge

EtherApps Forge was de workflow die in het hele onderzoek werd gebruikt. De tool controleerde elke bron, legde de bestanden en instellingen van de applicatie vast, bouwde en ondertekende het MSIX-pakket, en installeerde, startte en ruimde het daarna op als eerste test. De conclusie van het paper is bewust afgewogen: EtherApps Forge kan u helpen geschikte bestaande applicatiebronnen om te zetten in MSIX-pakketten die klaar zijn voor uw eigen validatie. Het is geen claim van een volledig onbeheerde, productierijpe migratie.

EtherApps Forge is een Windows-desktopapplicatie die in uw eigen omgeving draait, zodat vastleggingen en pakketten bij u blijven. De workflow voor agentische applicatiepackaging beveelt een route aan op basis van de werkelijke footprint van de applicatie, en de Package Support Framework-fix-ups helpen vastgelegde applicaties die bestands- of registeromleiding nodig hebben. Voor landschappen met jarenlang opgebouwde installers behandelt modernisering van legacy-applicaties inventarisatie en herstel. Eerdere papers uit hetzelfde onderzoeksprogramma kijken naar native MSIX versus App Attach voor Azure Virtual Desktop en waar het Package Support Framework risico toevoegt aan MSIX en App Attach.

De snelste manier om te zien of uw eigen applicaties zich gedragen zoals de cases in het onderzoek, is ze door dezelfde workflow te halen. EtherApps Forge bevat een gratis proefperiode van 7 dagen voor de volledige workflow, en elke licentie omvat training en ondersteuning.

Ontdek MSIX-packaging en -uitrol en zie hoe het bewijs in vier fasen uit het onderzoek een herhaalbaar packaging- en leveringsproces voor uw landschap wordt.