Solution
Je bouwt de software al. Er een ondertekende, gevalideerde MSIX van maken hoort een stap in je pipeline te zijn, geen apart project. De forge_msix-CLI van EtherApps Forge is een directe vervanger van makeappx.exe van Microsoft, dus een buildmap wordt een ondertekend, gevalideerd en getest package zonder Windows-SDK op de build-agent en zonder het script te herschrijven dat je al hebt.
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
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 |
The problem
Ontwikkelteams en softwareleveranciers zitten niet met hetzelfde probleem als een migratieteam. Hier is geen installer kwijt en valt niets vast te leggen: de build werkt al. De wrijving zit in alles wat daarna komt. MSIX-packaging betekende historisch een Windows-SDK-afhankelijkheid op de build-agent, een ondertekeningsstap die er achteraf op werd geplakt, certificaatbeheer waarvan niemand eigenaar is, en geen betrouwbare manier om een build te laten falen als het package niet deugt. Het gevolg is dat packagen een handmatige klus wordt die iemand op releasedag doet, en dat is precies waar fouten bij klanten terechtkomen.
Packagen met het standaardgereedschap betekent de Windows-SDK installeren en op versie vastzetten op elke agent. Dat is een zware afhankelijkheid voor één stap, en hij loopt tussen agents uiteen op een manier die pas op een releasedag opvalt.
Windows installeert geen niet-ondertekende MSIX, dus ondertekenen is niet optioneel. Het er na het packagen op plakken betekent meestal een certificaatbestand op schijf met het wachtwoord in een builddefinitie, of een handmatige stap door degene die het certificaat heeft.
Zonder validatiepoort die een ongeldig package onderscheidt van een mislukte run kan een kapot package de pipeline passeren en bij een klant belanden, waar het faalt bij installatie in plaats van bij de build.
Bij elke rebuild een volledig package bouwen is tijdens ontwikkeling onnodig en traag, dus teams testen de gepackagede vorm pas laat, en containerspecifiek gedrag overvalt ze aan het eind.
What changes
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.
How we deliver it
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
FAQ
Licenties, afhankelijkheden van de build-agent, ondertekening, en waarin dit verschilt van de capture-first route voor legacy-applicaties.
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.
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.
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.
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.
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.
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.
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.
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
Begin met de gratis proefperiode van 7 dagen van EtherApps Forge en package één echte build van begin tot eind, of praat met ons over de pipeline die je al draait en waar de packagingstap daarin hoort.
