Installerdetaljer äter utvecklingstid
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.
Solution
Paketera din Windows-app som signed MSIX.
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.
Utan SDK
CLI:t anropar Windows paketeringsmotor direkt på byggagenten
Licensfritt
de makeappx-kompatibla kommandona kräver ingen licens alls
Ett steg
skapa, signera, validera och testa inuti release-pipelinen
Så fungerar det
Bygg din MSIX med forge_msix i fem steg.
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.
Lägg forge_msix på build-agenten
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.
Peka på din publicerade buildmapp
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.
Förbered Appx-manifestet
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.
Skapa och signera i ett kommando
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.
Validera och leverera den signerade MSIX:en
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
Vad en release-pipeline behöver, och var standardverktyget tar slut
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 |
The problem
Varför utvecklare och ISV:er fortfarande brottas med MSIX-paketering.
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.
Build-agenten bär verktyg den inte borde behöva
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.
Enterprise-köpare kräver ett rent paket
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.
Ett dåligt paket fallerar tyst
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.
What changes
Vad som förändras för utvecklare och ISV:er
Direkt ersättare för makeappx
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.
Manifest, paket och signatur i ett steg
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.
En byggrind du kan lita på
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.
En snabbare inre loop och ett uppdateringsflöde
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.
Pipelinen från build till MSIX
Från build-mapp till signerad MSIX som ett pipelinesteg.
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.
How we deliver it
Produktmappning
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.
EtherApps Forge captures installed Windows applications from running systems, analyses the real application footprint, supports AI-guided packaging decisions, and produces deployment-ready outputs for modern environments.
Where this fits
- En ISV som levererar en Windows-skrivbordsprodukt som kunderna vill ha som signerad MSIX i stället för en äldre installer.
- Ett utvecklingsteam som redan publicerar en MSI eller setup.exe och behöver ett format som avinstalleras rent för enterprise-kunder.
- Distribution via direktnedladdning, där slutkunden installerar genom att öppna det signerade paketet.
- Enterprise-distribution via Microsoft Intune eller Configuration Manager när paketet är signerat och validerat.
- Sideload-distribution utanför en store, med en app installer-uppdateringsfeed i stället för manuell ominstallation.
- Byta ut makeappx.exe i ett CI-skript som redan fungerar, utan att skriva om pipelinen.
FAQ
Frågor som utvecklare och ISV:er ställer först.
Licensiering, build-agentberoenden, signering, CI-integration och hur detta skiljer sig från capture-first-vägen för äldre program.
Är det här samma sak som er fångst av legacy-applikationer?
Nej, 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.
Hur använder jag Forge för att bygga en MSIX från min app?
Lägg forge_msix på agentens PATH, peka på din publicerade buildmapp, kör forge_msix prepare för att skapa ett manifest från den byggda körbara filen och sedan forge_msix create med signering från certifikatlagret via thumbprint. Gatea releasen med forge_msix validate och generera vid behov en app installer-feed för sideload-uppdateringar. Samma växlar som ett befintligt makeappx-skript redan använder fortsätter att fungera.
Kan jag integrera forge_msix i min CI/CD-pipeline?
Ja. forge_msix är en CLI för obemannade agenter. Kör den från Azure DevOps, GitHub Actions, GitLab CI, Jenkins eller valfri skriptad Windows-buildagent. Paketering, signering och validering blir steg i samma releasedefinition som dina övriga artefakter.
Behöver vi en licens för att använda det i vår pipeline?
Inte för de makeappx-kompatibla kommandona. Att paketera, packa upp, bunta, avbunta, validera och indexera resurser är licensfritt, så forge_msix fungerar som en äkta direkt ersättare för makeappx.exe utan att något behöver köpas. De värdeskapande flödena, alltså att skapa från ett manifest, signera, testa, bedöma, hantera certifikat och utvecklarregistreringskommandona, kräver en aktiv EtherApps Forge-licens.
Behöver byggagenten ha Windows SDK installerat?
Nej. CLI:t anropar Windows paketerings-API direkt, och den motorn är en operativsystemkomponent i stället för ett SDK-beroende, så paket får samma schemakontroll, block map och struktur som makeappx producerar. Agenten behöver Windows 10 version 1709 eller senare, eller Windows 11, på x64. Driftsättningen är en mapp du kopierar och lägger i PATH, utan installationsprogram.
Hur bör vi hantera kodsignering i CI?
Signera från ett certifikatlager via tumavtryck eller subjekt i stället för från en PFX på disk, så att inget lösenord skrivs in i en byggdefinition. Lägg till en RFC 3161-tidsstämpelserver så att signaturer förblir giltiga efter att certifikatet gått ut. Sätt utgivaren i ert manifest exakt lika med certifikatets subjekt och låt utgivarläget vara strikt, så att en avvikelse stoppar bygget i stället för att tyst ändra den identitet era kunder redan installerat.
Hur låter vi bygget falera när paketet är fel?
Kör valideringskommandot med JSON-utdata och förgrena på exitkoden. Det skiljer ett analyserat men ogiltigt paket från ett driftfel, vilket är skillnaden mellan ett trasigt paket och en trasig agent. Håll de flaggor som låter ett bygge passera validerings- eller semantikfel utanför release-pipelines; de är diagnosverktyg för att ta reda på varför ett paket inte byggs, inte inställningar att lämna påslagna.
Kan vi paketera vårt eget bygge om det behöver containerfixar?
Ja. Applikationer skrivna före MSIX förutsätter ofta beteenden containern inte tillåter, som att skriva bredvid sin egen körbara fil eller förvänta sig en fast installationssökväg. Forge lägger upp Package Support Framework så att de fallen rättas med fil- och registeromdirigering och korrigering av arbetskatalogen, utan ändring i er källkod. För egen programvara vill ni kanske hellre rätta beteendet vid källan, men ramverket gör att en release inte blockeras under tiden.
Hur blir det med uppdateringar för kunder som sidoladdar i stället för att använda en butik?
Generera ett app installer-manifest från det signerade paketet; det härleder identiteten från paketet självt och hanterar bundles. Publicera paketet och det manifestet på en HTTPS-plats, så kan installerade kopior uppdatera sig själva därifrån. Det ger sidoladdande och företagskunder en uppdateringsväg utan butikspublicering eller manuell ominstallation.
Kan vi rätta ett paket vi redan levererat utan att bygga om det?
Ja. Ett paket kan extraheras till en arbetskatalog, redigeras kirurgiskt, valideras och paketeras om: manifestvärden, capabilities, payload-filer och paketets virtuella register går alla att ändra, och varje manifeständring valideras innan den skrivs, så en felformad ändring avvisas i stället för att sparas. Ompaketering ändrar innehållshashen, så paketet måste signeras igen efteråt.
Start here
Gör en signerad MSIX till en artefakt av bygget, inte ett jobb någon utför vid release.
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.
- Paketeringskommandona speglar makeappx ett till ett och kräver ingen licens, så ett fungerande CI-skript kan införa Forge genom att byta en binär i stället för att skriva om en pipeline.
- Paketering, signering, validering och röktest är steg i samma verktyg, så en signerad MSIX faller ut ur release-bygget bredvid alla andra artefakter i stället för att sättas ihop för hand vid release.
- Valideringen ger en egen exitkod för ett ogiltigt paket, så byggrinden fångar ett dåligt paket före en kund gör det.
- Forge är en Win32-applikation som driftsätts inuti din egen miljö, så byggartefakter och signeringscertifikat lämnar aldrig din pipeline.