Kan ett automatiserat arbetsflöde omvandla befintliga Windows-program till MSIX-paket i tusentals fall, och inte bara i en handfull demonstrationer? Vår nya studie svarar ja för en stor andel av de fall vi försökte: av 3 261 programfall gav 2 957 ett MSIX-paket (90,68 %) och 2 610 registrerade ett fullständigt godkänt smoke test (80,04 %). Rapporten, "MSIX at Scale: An Automated Packaging Study of 3,261 Windows Application Cases", är tillgänglig nu på Zenodo under en CC BY 4.0-licens med DOI 10.5281/zenodo.21985871, tillsammans med ett supplement som låter vem som helst räkna om varje siffra.
Om du driver en programportfölj för en organisation med 50 till 600 användare, eller paketerar program åt kunder som MSP, är frågan bakom den här forskningen välbekant. Du har installationsprogram, MSI-filer, ZIP-arkiv och portabla verktyg i alla tänkbara former. Att paketera om dem för hand går långsamt, varje paketerare gör det lite olika och eftersläpningen krymper sällan. Studien frågar om det arbetet kan upprepas tillförlitligt i stor volym, och den är noggrann med vad "fungerade" betyder.
Vad studien mätte
MSIX är Microsofts paketformat för att installera och hantera Windows-program. Ett paket samlar programfilerna tillsammans med ett manifest som talar om för Windows vad paketet innehåller och hur dess program startar. Microsofts egen vägledning för konvertering behandlar förberedelse, insamling, paketskapande och testning som separata steg, och studien håller också isär de stegen.
Vi analyserade poster, fastställda den 27 juni 2026, för varje fall där ett försök till MSIX-paketering registrerades. Programmen kom från sökningar i den offentliga katalogen för Windows Package Manager (WinGet). Varje försökt fall räknas i nämnaren, även de som stoppade tidigt, så huvudprocentsatserna kan inte blåsas upp genom att misslyckanden tyst tas bort.
Varje fall rapporterades i fyra steg:
- Paket skapat: MSIX-bygget slutfördes.
- Installerat och registrerat: paketet installerades för en testanvändare och Windows registrerade det.
- Startpunkt startad: ett valt program i paketet startade.
- Fullständigt godkänt smoke test: installation, start, stängning och rensning registrerades alla som lyckade, utan upptäckt krasch.
Ett smoke test är en kort första kontroll, inte ett fullständigt test. Det bekräftar att ett paket installeras, att ett valt program startar och att testet stänger och rensar upp. Det testar inte inloggning, redigering av ett dokument eller att spara data. Vi höll den skillnaden synlig genom hela rapporten, och vi håller den synlig här.
Resultaten
Varje procentsats använder alla 3 261 försökta fall. Stegen överlappar, så de får inte adderas.
Titta på var fallen faller bort. 304 försök gav inget paket, men nästan lika många, 281, installerades och registrerades felfritt och registrerade sedan inte att något program startade. Det är den praktiska lärdomen för varje paketeringsprogram: att en paketfil finns på disk, eller till och med installeras felfritt, är inte samma sak som ett program som körs. Byggframgång och programframgång måste rapporteras separat, annars ser en migreringsplan friskare ut än den är.
Godkända resultat kom också från varje källtyp i studien. Här är de fullständigt godkända smoke testen per typ av installationsprogram eller distribution:
| Typ av installationsprogram eller distribution | Fullständigt godkända | Försökta fall | Andel godkända |
|---|---|---|---|
| Portabel | 253 | 263 | 96,20 % |
| Nullsoft | 768 | 895 | 85,81 % |
| Inno Setup | 694 | 811 | 85,57 % |
| ZIP | 207 | 255 | 81,18 % |
| Burn | 43 | 54 | 79,63 % |
| WiX | 317 | 423 | 74,94 % |
| Generisk EXE | 220 | 357 | 61,62 % |
| MSI | 108 | 203 | 53,20 % |
| Totalt | 2 610 | 3 261 | 80,04 % |
Grupperna innehåller olika program med olika krav, så tabellen visar inte att en typ av installationsprogram orsakar en högre eller lägre chans att lyckas. Vad den visar är att lyckade resultat inte var begränsade till en enda sorts installationsprogram. Det spelar roll när din portfölj är en blandning av dem alla.
Hur vi kontrollerade underlaget
Siffror som dessa förtjänar granskning, så rapporten beskriver hur de testades innan vi publicerade dem.
- Varje godkänt resultat kontrollerades mot sin sparade rapport. Alla 2 610 registrerade godkända smoke test jämfördes med sina länkade ursprungliga testrapporter över de sex fälten för teststeg. Alla stämde överens.
- Dubblettrapporter identifierades. Filfingeravtryck visade sex par fall med identiska rapporter, så rapporten räknar katalogfall och sparade resultat, inte oberoende testkörningar.
- Vi rapporterade det obekväma fyndet. Två godkända fall startade ett inaktiveringsverktyg i stället för huvudprogrammet, och den automatiserade identitetskontrollen flaggade det inte. De ligger kvar i totalen enligt den angivna regeln, och rapporten använder dem som det tydligaste exemplet på varför en start inte bevisar att det avsedda programmet fungerar.
- Nya försök redovisas. De sparade historikerna innehåller 3 942 försökssammanfattningar: 2 712 fall hade ett försök, 417 hade två och 132 hade tre. Det här är arbetsflödesresultat, inte andelar som lyckades vid första försöket.
Supplementet innehåller resultaten per fall, urvalsanteckningar och Python-skript som återskapar varje tabell och procentsats.
Vad studien inte påstår
Begränsningarna är lika användbara som resultaten, särskilt om du planerar att dela den här forskningen med andra i din organisation.
- Det är inte en generell kompatibilitetsgrad. Programmen hämtades från katalogsökningar, inte ett slumpmässigt urval, och de representerar inte din programlista eller Windows-programvara i allmänhet.
- Det är inte ett bevis på produktionsberedskap. Testning av verksamhetsuppgifter, långsiktig tillförlitlighet och distribution till slutanvändare mättes inte.
- Det mäter inte tids- eller kostnadsbesparingar. Det gjordes ingen jämförelse med manuell paketering eller andra metoder.
- Det har inte upprepats oberoende. Rapporten är ett preprint och har inte granskats av oberoende forskare. Jag utvecklar EtherApps Forge, verktyget som användes i studien, och har ett kommersiellt intresse i resultaten. Den relationen redovisas i rapporten och bör vägas in av varje läsare.
Ett fall utan lyckat resultat är inte heller ett bevis på att programmet inte kan fungera med MSIX. Vissa program behöver fix-ups, ett annat paketformat eller en närmare granskning.
Vad det här betyder för ditt paketeringsprogram
För IT-chefer och MSP-ägare stöder forskningen en tydlig hållning: MSIX är ett praktiskt paketeringsalternativ för lämpliga befintliga Windows-program, och det hör hemma i din paketeringsstrategi. Det bör inte vara obligatoriskt för varje program, och beslutet fattas bäst program för program.
För de specialister som gör arbetet pekar rapporten på en beslutsprocess som du kan tillämpa på din egen portfölj:
- Testa med dina egna program. Utvärdera MSIX mot de program som din organisation faktiskt kör, inte mot en leverantörs exempellista.
- Håll isär stegen. Registrera paketskapande, installation, den första kontrollen och testning av verksamhetsuppgifter som separata resultat.
- Bekräfta att rätt program startar. Kontrollera att starttestet väljer det avsedda huvudprogrammet, inte ett hjälpprogram eller verktyg.
- Testa verkligt arbete. Inloggning, filhantering, integrationer, uppdateringar och längre användning, och därefter distribution till rena målenheter.
- Styr undantagen rätt. Program som behöver drivrutiner, tjänster eller datoromfattande ändringar kan höra hemma i ett annat format. Den capture-first-baserade vägen till MSIX för komplexa Windows-program beskriver hur du fattar det beslutet.
Tänk också på full-trust-beteende. Microsofts vägledning om containerisering anger att en paketerad full-trust-skrivbordsapp körs med samma behörigheter som en vanlig skrivbordsapp, så MSIX ger dig ren installation och borttagning, inte en automatisk säkerhetsgräns.
Om du behöver ta det här till en change board eller en kund ger DOI:n och det reproducerbara supplementet dig underlag som du kan vidarebefordra och som andra kan kontrollera.
Där EtherApps Forge passar in
EtherApps Forge var arbetsflödet som användes genom hela studien. Det kontrollerade varje källa, fångade programmets filer och inställningar, byggde och signerade MSIX-paketet och installerade, startade och rensade sedan upp det som ett första test. Rapportens slutsats är medvetet återhållsam: EtherApps Forge kan hjälpa dig att omvandla lämpliga befintliga programkällor till MSIX-paket som är redo för din egen validering. Det är inte ett påstående om en helt obevakad, produktionsklar migrering.
EtherApps Forge är ett Windows-skrivbordsprogram som körs i din egen miljö, så insamlingar och paket stannar hos dig. Dess arbetsflöde för agentisk programpaketering rekommenderar en väg utifrån programmets verkliga fotavtryck, och dess Package Support Framework-fix-ups hjälper insamlade program som behöver omdirigering av filer eller register. För portföljer med år av ackumulerade installationsprogram täcker modernisering av äldre program inventering och åtgärder. Tidigare rapporter från samma forskningsprogram tittar på inbyggd MSIX kontra App Attach för Azure Virtual Desktop och var Package Support Framework tillför risk för MSIX och App Attach.
Det snabbaste sättet att se om dina egna program beter sig som fallen i studien är att köra dem genom samma arbetsflöde. EtherApps Forge har en kostnadsfri 7-dagars provperiod av hela arbetsflödet, och varje licens inkluderar utbildning och support.
Utforska MSIX-paketering och distribution för att se hur studiens underlag i fyra steg blir en repeterbar process för paketering och leverans för din portfölj.
