Solution
Il software lo costruite già. Trasformarlo in un MSIX firmato e validato dovrebbe essere un passaggio della vostra pipeline, non un progetto a parte. La CLI forge_msix di EtherApps Forge è un sostituto diretto di makeappx.exe di Microsoft: una cartella di build diventa un pacchetto firmato, validato e verificato, senza un SDK di Windows sull'agente di build e senza riscrivere lo script che avete già.
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
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
I team di sviluppo e i produttori di software non sono bloccati dallo stesso problema di un team di migrazione. Qui non c'è nessun installer perduto e nulla da catturare: la build funziona già. L'attrito sta in tutto ciò che viene dopo. Il packaging MSIX ha storicamente significato una dipendenza dal Windows SDK sull'agente di build, un passaggio di firma aggiunto in un secondo momento, una gestione dei certificati che nessuno presidia e nessun modo affidabile di far fallire una build quando il pacchetto è sbagliato. Il risultato è che il packaging diventa un lavoro manuale che qualcuno fa al momento del rilascio, ed è esattamente lì che gli errori raggiungono i clienti.
Impacchettare con lo strumento standard significa installare e bloccare la versione del Windows SDK su ogni agente. È una dipendenza pesante per un solo passaggio, e si disallinea tra agenti in un modo che emerge solo il giorno del rilascio.
Windows non installa un MSIX non firmato, quindi firmare non è opzionale. Aggiungerla dopo il packaging di solito significa un file di certificato su disco con la password in una definizione di build, o un passaggio manuale eseguito da chi ha il certificato.
Senza un gate di validazione che distingua un pacchetto non valido da un'esecuzione fallita, un pacchetto rotto può attraversare la pipeline e arrivare a un cliente, dove fallisce al momento dell'installazione invece che della build.
Costruire un pacchetto completo a ogni ricompilazione durante lo sviluppo è inutile e lento, quindi i team smettono di provare la forma impacchettata fino a tardi, e il comportamento specifico del container li sorprende alla fine.
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.
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'agente di build, firma e in cosa questa strada differisce dal percorso capture-first pensato 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.
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
Iniziate con la prova gratuita di 7 giorni di EtherApps Forge e impacchettate una build reale dall'inizio alla fine, oppure parliamo della pipeline che già gestite e di dove dovrebbe collocarsi il passaggio di packaging.
