Installerdetails vreten ontwikkeltijd
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.
Solution
Pak je Windows-app als signed MSIX.
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.
Geen SDK
de CLI roept de Windows-packaging-engine rechtstreeks aan op de build-agent
Licentievrij
de makeappx-compatibele commando's hebben helemaal geen licentie nodig
Eén stap
aanmaken, ondertekenen, valideren en testen binnen de release-pipeline
Hoe het werkt
Bouw je MSIX met forge_msix in vijf stappen.
Je hebt de binaries al. Dit zijn de stappen die die build omzetten in een ondertekend pakket dat klanten kunnen installeren.
Zet forge_msix op de build-agent
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.
Wijs naar je gepubliceerde buildmap
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.
Maak het Appx-manifest klaar
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.
Maak en onderteken in één opdracht
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.
Valideer en lever de ondertekende MSIX
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
Wat een release-pipeline nodig heeft, en waar het standaardgereedschap ophoudt
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 |
The problem
Waarom ontwikkelaars en ISV’s nog worstelen met MSIX-packaging.
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.
De build-agent draagt tooling die niet nodig zou moeten zijn
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.
Enterprise-kopers vragen om een schoon pakket
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.
Een slecht pakket faalt stil
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.
What changes
Wat er verandert voor ontwikkelaars en ISV’s
Directe vervanger van makeappx
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.
Manifest, package en handtekening in één stap
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.
Een buildpoort die je kunt vertrouwen
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.
Een snellere inner loop en een updatefeed
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.
De build-naar-MSIX-pipeline
Van buildmap naar ondertekende MSIX als één pipelinestap.
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.
How we deliver it
Product-mapping
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.
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
- Een ISV die een Windows-desktopproduct levert dat klanten als ondertekende MSIX willen in plaats van een legacy-installer.
- Een ontwikkelteam dat al een MSI of setup.exe publiceert en een netjes te deïnstalleren formaat nodig heeft voor enterprise-klanten.
- Distributie via directe download, waarbij eindgebruikers installeren door het ondertekende pakket te openen.
- Enterprise-implementatie via Microsoft Intune of Configuration Manager zodra het pakket is ondertekend en gevalideerd.
- Sideload-distributie buiten een store, met een app installer-updatefeed in plaats van handmatige herinstallatie.
- makeappx.exe vervangen in een CI-script dat al werkt, zonder de pipeline te herschrijven.
FAQ
Vragen die ontwikkelaars en ISV’s eerst stellen.
Licenties, build-agentafhankelijkheden, ondertekening, CI-integratie en hoe dit verschilt van de capture-first-route voor legacy-toepassingen.
Is dit hetzelfde als jullie legacy-applicatiecapture?
Nee, 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.
Hoe gebruik ik Forge om een MSIX van mijn app te bouwen?
Zet forge_msix op het PATH van de agent, wijs naar je gepubliceerde buildmap, voer forge_msix prepare uit om een manifest te maken van de gebouwde executable, en daarna forge_msix create met ondertekening vanuit de certificatestore op thumbprint. Gate de release met forge_msix validate en genereer optioneel een app installer-feed voor sideload-updates. Dezelfde switches die een bestaand makeappx-script al gebruikt blijven werken.
Kan ik forge_msix in mijn CI/CD-pipeline integreren?
Ja. forge_msix is een CLI voor onbeheerde agents. Voer het uit vanuit Azure DevOps, GitHub Actions, GitLab CI, Jenkins of elke gescripte Windows-buildagent. Packaging, ondertekening en validatie worden stappen in dezelfde release-definitie als je overige artefacten.
Hebben we een licentie nodig om het in onze pipeline te gebruiken?
Niet voor de makeappx-compatibele commando's. Packagen, uitpakken, bundelen, ontbundelen, valideren en resources indexeren zijn licentievrij, dus forge_msix werkt als echte directe vervanger van makeappx.exe zonder dat er iets gekocht hoeft te worden. De toegevoegde-waarde-workflows, dus aanmaken vanuit een manifest, ondertekenen, testen, assessment, certificaatbeheer en de ontwikkelaarsregistratiecommando's, vereisen een actieve EtherApps Forge-licentie.
Moet de build-agent de Windows-SDK geïnstalleerd hebben?
Nee. De CLI roept de Windows-packaging-API rechtstreeks aan, en die engine is een besturingssysteemcomponent in plaats van een SDK-afhankelijkheid, dus packages krijgen dezelfde schemacontrole, block map en structuur die makeappx oplevert. De agent heeft Windows 10 versie 1709 of nieuwer, of Windows 11, op x64 nodig. Uitrollen is een map die je kopieert en aan PATH toevoegt, zonder installer.
Hoe pakken we code signing in CI aan?
Onderteken vanuit een certificate store op thumbprint of subject in plaats van vanuit een PFX op schijf, zodat er geen wachtwoord in een builddefinitie wordt geschreven. Voeg een RFC 3161-tijdstempelserver toe zodat handtekeningen geldig blijven nadat het certificaat verloopt. Zet de publisher in je manifest exact gelijk aan het certificaatsubject en laat de publisher-modus op strict, zodat een afwijking de build stopt in plaats van stilletjes de identiteit te wijzigen die je klanten al geïnstalleerd hebben.
Hoe laten we de build falen als het package niet deugt?
Draai het validatiecommando met JSON-uitvoer en vertak op de exitcode. Het onderscheidt een geanalyseerd maar ongeldig package van een operationele fout, en dat is het verschil tussen een kapot package en een kapotte agent. Houd de schakelaars die een build voorbij validatie- of semantische fouten laten lopen buiten release-pipelines; het zijn diagnosemiddelen om uit te zoeken waarom een package niet bouwt, geen instellingen om aan te laten staan.
Kunnen we onze eigen build packagen als die containerfixes nodig heeft?
Ja. Applicaties die vóór MSIX zijn geschreven gaan vaak uit van gedrag dat de container niet toestaat, zoals wegschrijven naast de eigen executable of een vast installatiepad verwachten. Forge zet het Package Support Framework klaar zodat die gevallen worden gecorrigeerd met bestands- en registry-omleiding en correcties van de werkmap, zonder wijziging van je broncode. Voor eigen software wil je het gedrag misschien liever bij de bron oplossen, maar het framework zorgt dat een release ondertussen niet geblokkeerd raakt.
Hoe zit het met updates voor klanten die sideloaden in plaats van een store te gebruiken?
Genereer een app installer-manifest uit het ondertekende package; het leidt de identiteit af uit het package zelf en is bundle-bewust. Publiceer het package en dat manifest op een HTTPS-locatie, dan kunnen geïnstalleerde kopieën zichzelf van daaruit bijwerken. Dat geeft sideload- en zakelijke klanten een updatepad zonder storevermelding of handmatige herinstallatie.
Kunnen we een al uitgeleverd package repareren zonder het opnieuw te bouwen?
Ja. Een package kan worden uitgepakt naar een werkmap, chirurgisch bewerkt, gevalideerd en opnieuw gepackaged: manifestwaarden, capabilities, payloadbestanden en de virtuele registry van het package zijn allemaal aanpasbaar, en elke manifestbewerking wordt gevalideerd voordat die wordt weggeschreven, zodat een misvormde wijziging wordt geweigerd in plaats van opgeslagen. Opnieuw packagen verandert de contenthash, dus het package moet daarna opnieuw worden ondertekend.
Start here
Maak van een ondertekende MSIX een artefact van de build, niet een klus die iemand op releasedag doet.
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.
- De packaging-commando's spiegelen makeappx één op één en hebben geen licentie nodig, dus een werkend CI-script kan Forge invoeren door een binary te vervangen in plaats van een pipeline te herschrijven.
- Packagen, ondertekenen, valideren en een smoke test zijn fasen van hetzelfde gereedschap, dus een ondertekende MSIX rolt uit de release-build naast elk ander artefact in plaats van op releasedag met de hand in elkaar te worden gezet.
- Validatie geeft een eigen exitcode voor een ongeldig package, dus de buildpoort onderschept een slecht package eerder dan een klant dat doet.
- Forge is een Win32-applicatie die in je eigen omgeving draait, dus buildartefacten en ondertekeningscertificaten verlaten je pipeline nooit.