Soluzione
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.
Prova gratuita di 7 giorni del workflow completo · le licenze includono formazione e supporto
Nessuna carta di credito. Cattura una vera applicazione il primo giorno.
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 |
Il problema
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.
Cosa cambia
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.
Forge MSIX CLI per costruire pipeline e fabbriche di imballaggio MSP: catturare, firmare e produrre un MSIX pronto per il deployment da un singolo comando. Non è richiesta la GUI.
Forge valuta ogni MSIX rispetto ai segnali delle migliori pratiche della stessa sessione CLI: capacità, allineamento dell'editore, asset visivi e stato di fiducia.
Inizia qui
Guardalo funzionare sul tuo tenant.
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à.
Come lo realizziamo
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.
Capture installed Windows applications, reduce packaging unknowns, and produce modern deployment-ready outputs faster.
Prova gratuita di 7 giorni del workflow completo · le licenze includono formazione e supporto
Domande
Licenze, dipendenze dell’agent di build, firma, integrazione CI e differenza rispetto alla route capture-first per le applicazioni legacy.
Chiedilo in un controllo di adattamento del packagingNo, 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.
Revisionato il 26 agosto 2026.
Inizia qui
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.
Nessuna carta di credito. Cattura una vera applicazione il primo giorno.
