EtherApps Forge 1.0.6: correzioni PSF e packaging MSIX per sviluppatori

EtherApps Forge 1.0.6 è disponibile e allarga il prodotto in due direzioni contemporaneamente. Le applicazioni legacy che si impacchettano senza problemi ma poi si comportano male dentro il container MSIX ora possono essere corrette con le correzioni del Package Support Framework predisposte come parte del packaging. E per la prima volta Forge non è solo per le applicazioni che catturate dall'ambiente di qualcun altro: la CLI forge_msix è un sostituto diretto di makeappx.exe di Microsoft, quindi un team di sviluppo o un produttore di software può trasformare la propria cartella di build in un MSIX firmato e validato dentro una pipeline esistente.

Entrambe le novità rispondono alla stessa lamentela dai due estremi opposti del problema del packaging. Costruire un pacchetto non è la parte difficile ormai da tempo. Farlo funzionare correttamente, e farlo funzionare correttamente a ogni build che esce, è dove sta il lavoro vero.

Correzioni di compatibilità PSF: quando l'app si impacchetta bene ma non si comporta

L'esito più frustrante in un programma MSIX non è un pacchetto che non si costruisce. È un pacchetto che si costruisce, si firma, si installa, si avvia e poi fa silenziosamente la cosa sbagliata.

Succede perché il container MSIX cambia le regole per cui un'applicazione più datata era stata scritta. Tre schemi ne causano la maggior parte:

• Scrivere accanto al proprio eseguibile. Le applicazioni che depositano impostazioni, log o file di licenza nella propria cartella di installazione scrivono in una posizione che il container protegge.
• Dare per scontato un percorso di installazione fisso. Qualsiasi cosa con un percorso C:\Program Files\Vendor\App scritto nel codice, o un launcher che si aspetta una directory di lavoro precisa, non trova nessuno dei due dove se li aspetta.
• Leggere posizioni di registro di macchina. La configurazione conservata sotto HKLM che il container redirige non è più dove l'applicazione la cerca.

Il Package Support Framework è la risposta open source di Microsoft esattamente a questo. Applica correzioni mirate a runtime, senza alcuna modifica al codice sorgente dell'applicazione, e quelle importanti sono la redirezione di file e registro più la correzione della directory di lavoro. Se un'applicazione legacy non ha più un produttore che la ricostruisca, il PSF è spesso la differenza tra un'applicazione che va in produzione e una che viene accantonata.

Dalla 1.0.6 Forge predispone il framework come parte del packaging invece di lasciarlo come passaggio manuale successivo. L'effetto pratico su una valutazione è che la categoria di applicazioni segnate come "distribuibile con correzioni" cresce in modo sensibile, e la categoria "non può ancora migrare" si riduce. Abbiamo scritto del perché questo livello di remediation conta per app attach e per la distribuzione MSIX in il Package Support Framework e il rischio MSIX app attach, e vale altrettanto direttamente per i pacchetti distribuiti via Intune su dispositivi fisici.

Packaging per sviluppatori e ISV: le vostre build, firmate e validate

Il packaging capture-first risolve un problema legacy: l'installer non c'è più, quindi l'applicazione in esecuzione diventa la fonte di verità. Non è mai stato tutto il mercato. Molti team hanno una cartella di build perfettamente sana e trovano comunque MSIX scomodo, perché gli strumenti intorno presuppongono un SDK di Windows installato, un passaggio di firma aggiunto dopo e una persona che controlli il risultato.

forge_msix è costruito come sostituto diretto di makeappx.exe. Richiama il motore di packaging di Windows direttamente invece di dipendere dall'SDK installato sull'agente di build, e i comandi di packaging accettano gli stessi switch, quindi uno script esistente continua a funzionare quando sostituite il binario.

Oltre alla parità, la release aggiunge le parti di cui una pipeline di release ha davvero bisogno:

# Scaffold a manifest from the built executable
forge_msix prepare .\publish\MyApp.exe
# Create and sign in one step, from the agent certificate store
forge_msix create -s .\publish --package-output .\artifacts\MyApp.msix `
  --sign --cert-sha1 $env:SIGNING_THUMBPRINT --cert-store My --cert-machine-store `
  --timestamp-server http://timestamp.digicert.com --validate-schema
# Gate the build on structural validation
forge_msix validate /p .\artifacts\MyApp.msix --json

Tre dettagli contano quando lo collegate alla CI. Firmate da un archivio certificati tramite thumbprint invece che da un PFX su disco, così nessuna password finisce in una definizione di build. Aggiungete una marca temporale RFC 3161 perché le firme restino valide dopo la scadenza del certificato. E ramificate sul codice di uscita, perché validate distingue "il pacchetto è stato analizzato ed è non valido" da "l'esecuzione stessa è fallita", che è la differenza tra una build rotta e un agente rotto.

C'è anche un comando di smoke test che installa il pacchetto firmato, lo avvia e lo chiude, lo disinstalla e scrive un report JSON, più un passaggio di valutazione che assegna un punteggio al pacchetto rispetto ai segnali di buona pratica del packaging. Nessuno dei due appartiene a ogni commit. Entrambi vale la pena eseguirli su una release candidate.

Per i team che distribuiscono fuori da uno store, make-appinstaller genera il manifest .appinstaller dall'identità reale del pacchetto firmato, così le copie installate in sideload possono aggiornarsi da una posizione HTTPS.

Cosa significa se il vostro ambiente è misto

La maggior parte delle organizzazioni non è puramente una cosa o l'altra. Hanno software acquistato con installer perduti, una manciata di applicazioni gestionali sviluppate internamente e una scadenza Windows 11 o Intune che le copre tutte. Finora quelle due metà seguivano percorsi e strumenti diversi.

Con la 1.0.6 condividono un percorso di packaging: capture-first per le applicazioni il cui installer è sparito, packaging da cartella di build per quelle che compilano i vostri sviluppatori, remediation PSF per tutto ciò che il container disturba, e alla fine la stessa firma, validazione e distribuzione via Intune. La decisione sul percorso resta di una persona. La meccanica smette di essere due progetti separati.

Disponibilità

EtherApps Forge 1.0.6.0 è disponibile ora. Forge è un'applicazione Win32 che distribuite dentro il vostro ambiente invece di un servizio ospitato, quindi catture e packaging restano sotto il vostro controllo, e cattura sia da versioni di Windows più datate sia da quelle attuali. Ogni licenza include formazione e supporto, e c'è una prova gratuita di 7 giorni perché un team di packaging, di endpoint o di sviluppo possa dimostrare il risultato su un'applicazione reale prima di impegnare il resto dell'ambiente.

Se il vostro blocco è un'applicazione legacy che nessuno può ricostruire, partite da modernizzare le applicazioni Windows legacy o dalla nostra guida su come reimpacchettare un'applicazione quando l'installer è perduto. Se il blocco è sul lato distribuzione, packaging e deployment MSIX copre firma, revisione PSF e rollout con Intune. Il prodotto in sé si trova su EtherApps Forge.

Prova EtherApps Forge gratis per 7 giorni e impacchetta un'applicazione reale, catturata o compilata, dalla sorgente all'MSIX firmato.