Lösning
Byggd för utvecklare och ISV:er som redan kompilerar en fungerande skrivbordsapp. Fokusera på produkten, inte på installer-teknik. forge_msix-CLI:n från EtherApps Forge gör en buildmapp till en signerad, validerad MSIX som ett pipeline-steg, utan Windows SDK på agenten och utan att skriva om skriptet du redan kör.
7 dagars kostnadsfri provperiod av hela arbetsflödet · licenser inkluderar utbildning och support
Inget kreditkort. Fånga en riktig applikation på dag ett.
Så fungerar det
Du har redan binärerna. Det här är stegen som gör om den builden till ett signerat paket som dina kunder kan installera.
Kopiera CLI-mappen till PATH. Ingen Windows SDK-installation och ingen versionspinning av SDK-verktyg mellan agenter. CLI:n anropar den paketeringsmotor som följer med Windows.
Börja från mappen som din CI redan producerar: körbara filer, beroenden och allt som ska ingå i paketet. Det finns inget att fånga in. Builden är källan till sanning.
Kör forge_msix prepare mot den byggda körbara filen för att skapa ett manifest från versionsresurser och arkitektur, eller behåll ett granskat manifest i källkontrollen och skicka in det.
Kör forge_msix create mot buildmappen med signering från certifikatlagret via thumbprint plus en RFC 3161-tidsstämpel. Publisher-identiteten justeras mot certifikatets subject så kunderna får en stabil paketidentitet.
Kör forge_msix validate och låt builden falla vid ett ogiltigt paket. Leverera artefakten för direktnedladdning, distribution via Microsoft Intune eller Configuration Manager, eller generera en app installer-uppdateringsfeed för sideload-kunder.
Passar pipelinen
Att paketera en build som MSIX är inte en uppgift. Det är manifest, paket, signering, validering, test och en uppdateringsväg. Jämfört per steg i stället för per produkt:
| Pipelinesteg | Standardverktyg i Windows SDK | forge_msix |
|---|---|---|
| Uppsättning av byggagenten | Windows SDK installerat och versionslåst på varje agent | En kopia av CLI-mappen i PATH. Den anropar motorn som följer med Windows |
| Manifest | Handskrivet och handhållet i takt med bygget | Genererat från den byggda filens versionsresurser, eller versionshanterat i repot och skickat in |
| Paketera och signera | Separata verktyg, signering påklistrad efter paketeringen | Ett kommando, med utgivaridentiteten anpassad till certifikatets subjekt |
| Låta bygget falera | Exitkoder skiljer inte ett ogiltigt paket från en misslyckad körning | Valideringen ger en egen kod för analyserat-men-ogiltigt, så grinden är entydig |
| Sidoladdade uppdateringar | App installer-manifest skrivet och underhållet för hand | Genererat från det signerade paketets verkliga identitet, bundle-medvetet |
Problemet
Utvecklare och ISV:er sitter inte fast i samma problem som ett migrationsteam. Det finns ingen förlorad installer och inget att fånga in: builden fungerar redan. Friktionen är allt som kommer efter. MSIX-paketering har betytt ett Windows SDK-beroende på agenten, ett signeringssteg som lagts till efteråt, certifikathantering utan tydlig ägare och inget tillförlitligt sätt att få en build att falla när paketet är fel. Paketering blir ett manuellt jobb vid release, just där fel når kunderna.
Oberoende mjukvaruleverantörer och produktteam lägger för mycket tid på Windows-paketeringsdetaljer i stället för att leverera funktioner. MSIX ska vara ett release-steg, inte ett sidoprojekt.
Att paketera med standardverktyget innebär att installera och versionslåsa Windows SDK på varje agent. Det är ett tungt beroende för ett enda steg, och det driver isär mellan agenter på ett sätt som ofta syns först på release-dagen.
Kunder som distribuerar med Intune eller Configuration Manager behöver ofta en signerad MSIX innan de köper. Om paketeringen är långsam eller manuell blir den ett kommersiellt hinder, inte bara ett tekniskt.
Utan en valideringsgrind som skiljer ett ogiltigt paket från en misslyckad körning kan ett trasigt paket passera pipelinen och nå en kund, där det fallerar vid installation i stället för vid build.
Vad som förändras
Paketeringskommandona tar samma flaggor som makeappx.exe, så ett befintligt skript fortsätter fungera när binären byts. De kommandona är licensfria, så införandet börjar inte med ett inköpssamtal, och motorn är operativsystemets komponent i stället för en omimplementering.
Generera ett manifest från den byggda filens versionsresurser och arkitektur, eller håll ett i versionshanteringen så att identitet, utgivare och capabilities granskas som vilken fil som helst. Skapa och signera sedan med ett kommando, från ett certifikatlager via tumavtryck så att inget lösenord skrivs in i en byggdefinition, med en RFC 3161-tidsstämpel så att signaturer överlever certifikatet.
Schemavalidering körs som förhandskontroll, och valideringskommandot ger en egen exitkod för ett paket som analyserats och befunnits ogiltigt, skilt från en körning som helt enkelt misslyckades. På en release candidate installerar ett röktest det signerade paketet, startar och stänger det, avinstallerar det och skriver en JSON-rapport, och en bedömningsomgång poängsätter det mot god paketeringspraxis.
Registrera under utveckling byggresultatet som ett löst paket i stället för att paketera om vid varje ombyggnad, och validera, starta och städa sedan i en enda omgång mot en isolerad stagingkopia. För sidoladdad distribution genererar du ett app installer-manifest från det signerade paketets verkliga identitet, så att installerade kopior uppdaterar sig själva från en HTTPS-plats.
Forge MSIX CLI för build-pipelines och MSP-paketeringsfabriker: fånga, signera och producera en deployment-färdig MSIX från ett enda kommando. Ingen GUI krävs.
Forge bedömer varje MSIX mot best practice-signaler från samma CLI-session: capabilities, publisher-alignment, visuella assets och trust-tillstånd.
Börja här
Se det här fungera i din egen tenant.
Pipelinen från build till MSIX
forge_msix genererar ett manifest från den byggda filen, paketerar och signerar med ett kommando, validerar resultatet med en exitkod som låter bygget falera, och producerar en signerad MSIX. En kort förgrening publicerar ett app installer-uppdateringsflöde för sidoladdande kunder. Varje steg körs inuti release-pipelinen ni redan har.
Så levererar vi det
Den här rutten leds av EtherApps Forge, närmare bestämt av dess forge_msix-CLI. Forge är en Win32-applikation som du driftsätter inuti din egen miljö i stället för en värdbaserad tjänst, så byggartefakter, certifikat och paketering stannar under din kontroll och inuti din pipeline. Har samma organisation också inköpt programvara med förlorade installationsprogram täcker capture-first-rutten på sidan MSIX-paketering och deployment den halvan av miljön via samma signerings- och leveransväg.
Capture installed Windows applications, reduce packaging unknowns, and produce modern deployment-ready outputs faster.
7 dagars kostnadsfri provperiod av hela arbetsflödet · licenser inkluderar utbildning och support
Frågor
Licensiering, build-agentberoenden, signering, CI-integration och hur detta skiljer sig från capture-first-vägen för äldre program.
Fråga oss i en paketerings-fitcheckNej, och skillnaden spelar roll. Capture-first-paketering finns för applikationer vars installationsprogram är borta, så att den körande applikationen blir sanningskällan. Den här rutten förutsätter motsatsen: ni har en fungerande build-mapp och vill få den paketerad, signerad och validerad som ett pipelinesteg. Båda delar samma signerings-, validerings- och Intune-leveransväg på slutet, vilket är varför miljöer med både inköpt och egenbyggd programvara kan använda en rutt för båda.
Granskad 26 augusti 2026.
Börja här
Börja med den kostnadsfria 7-dagarsprovperioden av EtherApps Forge och paketera en verklig utvecklare- eller ISV-build från början till slut, eller prata med oss om pipelinen du redan kör och var paketeringssteget ska sitta.
Inget kreditkort. Fånga en riktig applikation på dag ett.
