Solution
Ni bygger redan programvaran. Att göra den till en signerad, validerad MSIX borde vara ett steg i er pipeline, inte ett eget projekt. forge_msix-CLI:t från EtherApps Forge är en direkt ersättare för Microsofts makeappx.exe, så en build-mapp blir ett signerat, validerat och testat paket utan Windows-SDK på byggagenten och utan att skriva om skriptet ni redan har.
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
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 |
The problem
Utvecklingsteam och programvaruleverantörer sitter inte fast i samma problem som ett migrationsteam. Här finns inget förlorat installationsprogram och inget att fånga: bygget fungerar redan. Friktionen ligger i allt som kommer efteråt. MSIX-paketering har historiskt inneburit ett Windows SDK-beroende på byggagenten, ett signeringssteg påklistrat i efterhand, certifikathantering som ingen äger, och inget tillförlitligt sätt att låta ett bygge falera när paketet är fel. Resultatet är att paketering blir ett manuellt jobb någon gör vid release, vilket är precis där misstagen når kunderna.
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 glider isär mellan agenter på ett sätt som bara syns på en releasedag.
Windows installerar inte en osignerad MSIX, så signering är inte valfritt. Att klistra på den efter paketeringen brukar betyda en certifikatfil på disk med lösenordet i en byggdefinition, eller ett manuellt steg utfört av den som har certifikatet.
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 falerar vid installation i stället för vid bygget.
Att bygga ett fullt paket vid varje ombyggnad under utveckling är onödigt och långsamt, så team slutar testa den paketerade formen tills sent, och containerspecifikt beteende överraskar dem på slutet.
What changes
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.
How we deliver it
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
FAQ
Licensiering, beroenden på byggagenten, signering, och hur det här skiljer sig från capture-first-rutten som byggts för 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.
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.
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.
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.
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.
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.
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.
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
Börja med den kostnadsfria 7-dagars provperioden av EtherApps Forge och paketera ett riktigt bygge från början till slut, eller prata med oss om pipelinen ni redan kör och var paketeringssteget bör sitta i den.
