Solution
Pensato per sviluppatori e ISV che compilano già un’app desktop funzionante. Concentrati sul prodotto, non sulla meccanica dell’installer. La CLI forge_msix di EtherApps Forge trasforma una cartella di build in un MSIX firmato e validato come fase di pipeline, senza Windows SDK sull’agent e senza riscrivere lo script che già esegui.
Senza SDK
la CLI richiama il motore di packaging di Windows direttamente sull'agente di build
Senza licenza
i comandi compatibili makeappx non richiedono alcuna licenza
Un passaggio
creare, firmare, validare e testare dentro la pipeline di release
Come funziona
Hai già i binari. Questi sono i passaggi che trasformano quella build in un pacchetto firmato che i clienti possono installare.
Copia la cartella della CLI nel PATH. Nessuna installazione del Windows SDK e nessun pinning di versione degli strumenti SDK tra agent. La CLI chiama il motore di packaging incluso in Windows.
Parti dalla cartella che la CI produce già: eseguibili, dipendenze e tutto ciò che deve entrare nel pacchetto. Non c’è nulla da catturare. La build è la fonte di verità.
Esegui forge_msix prepare sull’eseguibile compilato per generare un manifesto dalle risorse di versione e dall’architettura, oppure tieni un manifesto revisionato nel controllo del codice e passalo.
Esegui forge_msix create sulla cartella di build con firma dall’archivio certificati tramite thumbprint, più un timestamp RFC 3161. L’identità publisher è allineata al subject del certificato così i clienti ottengono un’identità pacchetto stabile.
Esegui forge_msix validate e fai fallire la build su un pacchetto non valido. Consegna l’artefatto per download diretto, distribuzione con Microsoft Intune o Configuration Manager, oppure genera un feed di aggiornamento app installer per clienti in sideload.
Adattamento alla pipeline
Impacchettare una build come MSIX non è un compito solo. È manifest, pacchetto, firma, validazione, test e una via di aggiornamento. Confrontati per fase invece che per prodotto:
| Fase della pipeline | Strumento predefinito del Windows SDK | forge_msix |
|---|---|---|
| Preparazione dell'agente | Windows SDK installato e con versione bloccata su ogni agente | Una copia della cartella della CLI nel PATH. Richiama il motore incluso in Windows |
| Manifest | Scritto a mano e tenuto allineato alla build a mano | Generato dalle risorse di versione dell'eseguibile, oppure versionato nel repository e passato come parametro |
| Impacchettare e firmare | Strumenti separati, firma aggiunta dopo il packaging | Un solo comando, con l'identità del publisher allineata al soggetto del certificato |
| Far fallire la build | I codici di uscita non distinguono un pacchetto non valido da un'esecuzione fallita | La validazione restituisce un codice dedicato per analizzato-ma-non-valido, quindi il gate è inequivocabile |
| Aggiornamenti sideload | Manifest app installer scritto e mantenuto a mano | Generato dall'identità reale del pacchetto firmato, compatibile con i bundle |
The problem
Sviluppatori e ISV non hanno lo stesso problema di un team di migrazione. Non c’è un installer perso e nulla da catturare: la build funziona già. L’attrito è tutto ciò che viene dopo. Il packaging MSIX ha significato una dipendenza dal Windows SDK sull’agent, un passaggio di firma aggiunto dopo, certificati senza un chiaro owner e nessun modo affidabile di far fallire la build quando il pacchetto è sbagliato. Il packaging diventa un lavoro manuale al momento del release, esattamente dove gli errori arrivano ai clienti.
I vendor di software indipendenti e i team di prodotto passano troppo tempo sulle peculiarità del packaging Windows invece di consegnare funzionalità. MSIX dovrebbe essere un passaggio di release, non un progetto parallelo.
Pacchettizzare con lo strumento standard significa installare e fissare la versione del Windows SDK su ogni agent. È una dipendenza pesante per un solo passaggio e diverge tra agent in un modo che emerge spesso solo il giorno del release.
I clienti che distribuiscono con Intune o Configuration Manager spesso richiedono un MSIX firmato prima di acquistare. Se il packaging è lento o manuale, diventa un blocco commerciale, non solo tecnico.
Senza un gate di validazione che distingua un pacchetto non valido da un’esecuzione fallita, un pacchetto rotto può attraversare la pipeline e raggiungere un cliente, dove fallisce in installazione invece che in build.
What changes
I comandi di packaging accettano gli stessi switch di makeappx.exe, quindi uno script esistente continua a funzionare quando si sostituisce il binario. Quei comandi sono senza licenza, quindi l'adozione non inizia con una conversazione con l'ufficio acquisti, e il motore è il componente del sistema operativo invece di una reimplementazione.
Generate un manifest dalle risorse di versione e dall'architettura dell'eseguibile compilato, oppure tenetene uno nel controllo di versione così che identità, publisher e capability siano rivisti come qualsiasi altro file. Poi create e firmate con un solo comando, da un archivio certificati tramite thumbprint così che nessuna password finisca in una definizione di build, con una marca temporale RFC 3161 così che le firme sopravvivano al certificato.
La validazione dello schema gira come preflight, e il comando di validazione restituisce un codice di uscita dedicato per un pacchetto analizzato e risultato non valido, distinto da un'esecuzione semplicemente fallita. Su una release candidate uno smoke test installa il pacchetto firmato, lo avvia e lo chiude, lo disinstalla e scrive un report JSON, e un passaggio di valutazione lo misura rispetto alle buone pratiche di packaging.
Durante lo sviluppo registrate l'output di build come pacchetto sciolto invece di reimpacchettare a ogni ricompilazione, poi validate, avviate e ripulite in un unico passaggio contro una copia di staging isolata. Per la distribuzione sideload generate un manifest app installer dall'identità reale del pacchetto firmato, così le copie installate si aggiornano da sole da una posizione HTTPS.
La pipeline dalla build al MSIX
forge_msix genera un manifest dall'eseguibile compilato, impacchetta e firma con un solo comando, valida il risultato con un codice di uscita che fa fallire la build, e produce un MSIX firmato. Una breve diramazione pubblica un feed di aggiornamento app installer per i clienti in sideload. Ogni fase gira dentro la pipeline di release che avete già.
How we deliver it
Questa strada è guidata da EtherApps Forge, in particolare dalla sua CLI forge_msix. Forge è un'applicazione Win32 che distribuite dentro il vostro ambiente invece di un servizio ospitato, quindi artefatti di build, certificati e packaging restano sotto il vostro controllo e dentro la vostra pipeline. Se la stessa organizzazione ha anche software acquistato con installer perduti, la strada capture-first della pagina packaging e deployment MSIX copre quella metà dell'ambiente attraverso lo stesso percorso di firma e distribuzione.
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
Licenze, dipendenze dell’agent di build, firma, integrazione CI e differenza rispetto alla route capture-first per le applicazioni legacy.
No, e la distinzione conta. Il packaging capture-first esiste per le applicazioni il cui installer è perduto, così l'applicazione in esecuzione diventa la fonte di verità. Questa strada presuppone l'opposto: avete una cartella di build sana e volete che venga impacchettata, firmata e validata come passaggio della pipeline. Alla fine entrambe condividono lo stesso percorso di firma, validazione e distribuzione via Intune, ed è per questo che gli ambienti con software acquistato e autoprodotto possono usare una sola strada per entrambi.
Metti forge_msix nel PATH dell’agent, punta alla cartella di build pubblicata, esegui forge_msix prepare per generare un manifesto dall’eseguibile compilato, poi forge_msix create con firma dall’archivio certificati tramite thumbprint. Controlla il release con forge_msix validate e, se serve, genera un feed app installer per gli aggiornamenti sideload. Gli stessi switch già usati da uno script makeappx continuano a funzionare.
Sì. forge_msix è una CLI pensata per agent non presidiati. Eseguila da Azure DevOps, GitHub Actions, GitLab CI, Jenkins o qualsiasi agent di build Windows con script. Packaging, firma e validazione diventano fasi della stessa definizione di release degli altri artefatti.
Non per i comandi compatibili makeappx. Impacchettare, spacchettare, creare e scomporre bundle, validare e indicizzare risorse sono senza licenza, quindi forge_msix funziona come vero sostituto diretto di makeappx.exe senza nulla da acquistare. I flussi a valore aggiunto, cioè creare da un manifest, firmare, testare, valutare, gestire i certificati e i comandi di registrazione per lo sviluppo, richiedono una licenza EtherApps Forge attiva.
No. La CLI richiama direttamente l'API di packaging di Windows, e quel motore è un componente del sistema operativo invece di una dipendenza dall'SDK, quindi i pacchetti ottengono la stessa validazione dello schema, la stessa block map e la stessa struttura prodotte da makeappx. L'agente deve avere Windows 10 versione 1709 o successiva, oppure Windows 11, su x64. La distribuzione è una cartella che copiate e mettete nel PATH, senza installer.
Firmate da un archivio certificati tramite thumbprint o soggetto invece che da un PFX su disco, così nessuna password finisce in una definizione di build. Aggiungete un server di marca temporale RFC 3161 così che le firme restino valide dopo la scadenza del certificato. Impostate il publisher nel vostro manifest esattamente uguale al soggetto del certificato e lasciate la modalità publisher su strict, così una discrepanza ferma la build invece di cambiare silenziosamente l'identità che i vostri clienti hanno già installato.
Eseguite il comando di validazione con output JSON e ramificate sul codice di uscita. Distingue un pacchetto analizzato ma non valido da un fallimento operativo, che è la differenza tra un pacchetto rotto e un agente rotto. Tenete fuori dalle pipeline di rilascio gli switch che permettono a una build di proseguire oltre errori di validazione o semantici; sono strumenti diagnostici per capire perché un pacchetto non si costruisce, non impostazioni da lasciare attive.
Sì. Le applicazioni scritte prima di MSIX spesso presuppongono comportamenti che il container non consente, come scrivere accanto al proprio eseguibile o aspettarsi un percorso di installazione fisso. Forge predispone il Package Support Framework perché quei casi vengano corretti con redirezione di file e registro e correzioni della directory di lavoro, senza modifiche al vostro codice sorgente. Per il software proprio potreste preferire correggere il comportamento alla fonte, ma il framework evita che un rilascio resti bloccato nel frattempo.
Generate un manifest app installer dal pacchetto firmato: deriva l'identità dal pacchetto stesso ed è compatibile con i bundle. Pubblicate il pacchetto e quel manifest in una posizione HTTPS, e le copie installate potranno aggiornarsi da lì. Questo dà ai clienti sideload ed enterprise una via di aggiornamento senza una pubblicazione su store e senza reinstallazione manuale.
Sì. Un pacchetto può essere estratto in una directory di lavoro, modificato chirurgicamente, validato e reimpacchettato: valori del manifest, capability, file di payload e registro virtuale del pacchetto sono tutti modificabili, e ogni modifica al manifest viene validata prima di essere scritta, così una modifica malformata viene rifiutata invece che salvata. Reimpacchettare cambia l'hash del contenuto, quindi il pacchetto deve essere firmato di nuovo dopo.
Start here
Inizia con la prova gratuita di 7 giorni di EtherApps Forge e pacchetta end-to-end una build reale di sviluppatore o ISV, oppure parlaci della pipeline che già esegui e di dove deve inserirsi il passaggio di packaging.
