Oplossing
Gemaakt voor ontwikkelaars en ISV’s die al een werkende desktop-app compileren. Focus op je product, niet op installer-techniek. De forge_msix CLI van EtherApps Forge maakt van een buildmap een ondertekende, gevalideerde MSIX als pipeline-stap, zonder Windows SDK op de agent en zonder het script te herschrijven dat je al draait.
Gratis proefperiode van 7 dagen op de volledige workflow · licenties zijn inclusief training en support
Geen creditcard. Vang een echte applicatie op dag één.
Hoe het werkt
Je hebt de binaries al. Dit zijn de stappen die die build omzetten in een ondertekend pakket dat klanten kunnen installeren.
Kopieer de CLI-map naar PATH. Geen Windows SDK-installatie en geen versie-pinning van SDK-tools over agents heen. De CLI roept de packaging-engine aan die bij Windows hoort.
Begin bij de map die je CI al produceert: uitvoerbare bestanden, afhankelijkheden en alles wat in het pakket hoort. Er is niets om te capturen. De build is de bron van waarheid.
Voer forge_msix prepare uit op de gebouwde executable om een manifest te maken vanuit versieresources en architectuur, of houd een beoordeeld manifest in bronbeheer en geef het door.
Voer forge_msix create uit op de buildmap met ondertekening vanuit de certificatestore op thumbprint, plus een RFC 3161-tijdstempel. Publisher-identiteit wordt uitgelijnd op het certificaatsubject zodat klanten een stabiele pakketidentiteit krijgen.
Voer forge_msix validate uit en laat de build falen bij een ongeldig pakket. Lever het artefact voor directe download, Microsoft Intune- of Configuration Manager-implementatie, of genereer een app installer-updatefeed voor sideload-klanten.
Past in de pipeline
Een build als MSIX packagen is niet één taak. Het is manifest, package, ondertekening, validatie, test en een updatepad. Vergeleken per fase in plaats van per product:
| Pipelinefase | Standaard Windows-SDK-gereedschap | forge_msix |
|---|---|---|
| Inrichten van de build-agent | Windows-SDK geïnstalleerd en op versie vastgezet op elke agent | Een kopie van de CLI-map in PATH. Die roept de engine aan die met Windows meekomt |
| Manifest | Handmatig geschreven en handmatig in de pas gehouden met de build | Gegenereerd uit de versiebronnen van de executable, of in versiebeheer gehouden en meegegeven |
| Packagen en ondertekenen | Losse tools, ondertekening achteraf erop geplakt | Eén commando, met de publisher-identiteit uitgelijnd op het certificaatsubject |
| De build laten falen | Exitcodes scheiden een ongeldig package niet van een mislukte run | Validatie geeft een eigen code voor geanalyseerd-maar-ongeldig, dus de poort is eenduidig |
| Sideload-updates | App installer-manifest met de hand geschreven en onderhouden | Gegenereerd uit de echte identiteit van het ondertekende package, bundle-bewust |
Het probleem
Ontwikkelaars en ISV’s zitten niet vast op hetzelfde probleem als een migratieteam. Er is geen verloren installer en niets om te capturen: de build werkt al. De frictie is alles erna. MSIX-packaging betekende een Windows SDK-afhankelijkheid op de agent, een later toegevoegde ondertekeningsstap, certificaatbeheer zonder duidelijke eigenaar, en geen betrouwbare manier om een build te laten falen wanneer het pakket fout is. Packaging wordt handwerk op release-moment, precies waar fouten klanten bereiken.
Onafhankelijke softwareleveranciers en productteams besteden te veel tijd aan Windows-packagingeigenaardigheden in plaats van functies te leveren. MSIX hoort een release-stap te zijn, geen nevenproject.
Packagen met de standaardtool betekent het Windows SDK op elke agent installeren en vastzetten. Dat is een zware afhankelijkheid voor één stap, en het drijft tussen agents uit op een manier die vaak pas op release-dag zichtbaar wordt.
Klanten die met Intune of Configuration Manager deployen hebben vaak een ondertekende MSIX nodig voordat ze kopen. Als packaging traag of handmatig is, wordt het een commercieel blokkadepunt, niet alleen een technisch.
Zonder een validatiegate die een ongeldig pakket scheidt van een mislukte run kan een kapot pakket de pipeline doorstaan en een klant bereiken, waar het faalt bij installatie in plaats van bij de build.
Wat verandert
De packaging-commando's nemen dezelfde schakelaars als makeappx.exe, dus een bestaand script blijft werken als de binary wordt vervangen. Die commando's zijn licentievrij, dus invoering begint niet met een inkoopgesprek, en de engine is de besturingssysteemcomponent in plaats van een herimplementatie.
Genereer een manifest uit de versiebronnen en architectuur van de gebouwde executable, of houd er een in versiebeheer zodat identiteit, publisher en capabilities net als elk ander bestand worden gereviewd. Maak en onderteken daarna in één commando, vanuit een certificate store op thumbprint zodat er geen wachtwoord in een builddefinitie belandt, met een RFC 3161-tijdstempel zodat handtekeningen het certificaat overleven.
Schemavalidatie draait als preflight, en het validatiecommando geeft een eigen exitcode voor een package dat is geanalyseerd en ongeldig bevonden, los van een run die simpelweg mislukte. Op een release candidate installeert een smoke test het ondertekende package, start en sluit het, deïnstalleert het en schrijft een JSON-rapport, en een assessmentronde scoort het tegen best practices voor packaging.
Registreer tijdens ontwikkeling de buildoutput als los package in plaats van bij elke rebuild opnieuw te packagen, en valideer, start en ruim daarna in één pass op tegen een geïsoleerde stagingkopie. Genereer voor sideload-distributie een app installer-manifest uit de echte identiteit van het ondertekende package, zodat geïnstalleerde kopieën zichzelf bijwerken vanaf een HTTPS-locatie.
Forge MSIX CLI voor build pipelines en MSP packaging factories: vang, sign en lever een deployment-ready MSIX uit één commando. Geen GUI nodig.
Forge beoordeelt elke MSIX tegen best-practice signalen vanuit dezelfde CLI-sessie: capabilities, publisher alignment, visuele assets en trust-state.
Begin hier
Bekijk dit werkend in uw eigen tenant.
De build-naar-MSIX-pipeline
forge_msix genereert een manifest uit de gebouwde executable, packaget en ondertekent in één commando, valideert het resultaat met een exitcode die de build laat falen, en levert een ondertekende MSIX. Een korte aftakking publiceert een app installer-updatefeed voor sideload-klanten. Elke fase draait binnen de release-pipeline die je al hebt.
Hoe we dit leveren
Deze route wordt geleid door EtherApps Forge, en specifiek door de forge_msix-CLI. Forge is een Win32-applicatie die je in je eigen omgeving uitrolt in plaats van een gehoste dienst, dus buildartefacten, certificaten en packaging blijven onder jouw controle en binnen je pipeline. Heeft dezelfde organisatie ook ingekochte software met verdwenen installers, dan dekt de capture-first route op de pagina MSIX-packaging en deployment die helft van het landschap via hetzelfde signing- en leverpad.
Capture installed Windows applications, reduce packaging unknowns, and produce modern deployment-ready outputs faster.
Gratis proefperiode van 7 dagen op de volledige workflow · licenties zijn inclusief training en support
Vragen
Licenties, build-agentafhankelijkheden, ondertekening, CI-integratie en hoe dit verschilt van de capture-first-route voor legacy-toepassingen.
Vraag het ons in een packaging fit checkNee, en het onderscheid doet ertoe. Capture-first packaging bestaat voor applicaties waarvan de installer kwijt is, zodat de draaiende applicatie de bron van waarheid wordt. Deze route gaat uit van het omgekeerde: je hebt een gezonde buildmap en wilt die als pipelinestap gepackaged, ondertekend en gevalideerd hebben. Beide delen aan het eind hetzelfde signing-, validatie- en Intune-leverpad, en daarom kunnen landschappen met ingekochte én zelfgebouwde software één route voor beide gebruiken.
Beoordeeld op 26 augustus 2026.
Begin hier
Begin met de gratis 7-daagse proef van EtherApps Forge en package één echte ontwikkelaar- of ISV-build van begin tot eind, of praat met ons over de pipeline die je al draait en waar de packagingstap moet zitten.
Geen creditcard. Vang een echte applicatie op dag één.
