Come convertire un EXE in MSIX, dall'inizio alla fine

Convertire un EXE in MSIX è semplice quando l'installer si comporta bene e davvero difficile quando non lo fa. La maggior parte delle guide copre il primo caso. Questa copre l'intero percorso, comprese le parti in cui va storto, perché è lì che se ne va davvero il tempo.

Lo stato finale è un pacchetto MSIX firmato che si installa in modo pulito, si disinstalla in modo pulito e si distribuisce tramite Intune.

Prima di iniziare: MSIX è la destinazione giusta?

Vale trenta secondi, perché fa risparmiare giorni.

MSIX si adatta alle normali applicazioni desktop in modalità utente. Non si adatta a nulla che installi un driver, registri un servizio di sistema, debba scrivere in posizioni a livello di macchina lette da altre applicazioni, o si agganci in profondità al sistema operativo. Se il vostro EXE fa una di queste cose, confezionatelo come MSI o tramite il PowerShell App Deployment Toolkit e andate avanti. Forzarlo dentro MSIX produce un pacchetto che tecnicamente esiste e non funziona mai del tutto.

Tre domande risolvono la maggior parte dei casi prima di aprire qualsiasi strumento:

• L'installer ha bisogno di diritti amministrativi per qualcosa oltre alla scrittura in Program Files? Scrivere in Program Files è normale. Installare un servizio, un driver o un hook a livello di sistema è il segnale per fermarsi.
• Qualcos'altro legge ciò che questa applicazione scrive? MSIX reindirizza le scritture in un contenitore per utente, quindi se un'altra applicazione, un'operazione pianificata o un agente di monitoraggio legge un file o una chiave prodotta da questa, il reindirizzamento rende quei dati invisibili per loro. Sembra un pacchetto funzionante e non lo è.
• Il fornitore distribuisce già un MSIX? Chiedete prima di catturare. Riconfezionare un installer che ha un MSIX supportato è lavoro che potete semplicemente non fare.

Se non siete sicuri, eseguite comunque la conversione ma datele un limite di tempo. Il fallimento sarà evidente.

Sei passi, un ciclo: una diagnosi fallita vi rimanda allo snapshot, non avanti con un pacchetto rattoppato.

Passo 1: una macchina davvero pulita

Questo è il passo che le persone saltano e poi pagano.

La cattura funziona confrontando la macchina prima e dopo l'installazione. Tutto ciò che è già presente è invisibile a quel confronto, quindi una macchina con le dipendenze dell'applicazione già installate produce un pacchetto che funziona sulla vostra macchina e da nessun'altra parte.

Usate una macchina virtuale nuova, corrispondente alla build Windows di destinazione, senza nulla oltre al sistema operativo. Fatene uno snapshot prima di iniziare, così da poter tornare a uno stato noto, perché lo farete più di una volta.

Due dettagli fanno la differenza tra una cattura pulita e una rumorosa:

• Mettete prima a tacere la macchina. Windows Update, le definizioni di sicurezza e gli aggiornamenti delle app dello store scrivono tutti su disco mentre la cattura è in corso, e ognuna di quelle scritture diventa parte del pacchetto. Lasciate che la macchina completi gli aggiornamenti iniziali, sospendeteli, poi fate lo snapshot.
• Fate corrispondere la build, non solo la versione. Catturare su una build Windows più recente di quella del vostro parco incorpora redistributable e versioni di framework presenti lì e assenti sulla destinazione. Catturate sulla build più vecchia che supportate.

Un tentativo di cattura su una macchina che porta già un'installazione fallita non vale nulla, quindi ripristinate prima di ogni nuovo tentativo.

Passo 2: catturate l'installazione

Rilevate la baseline, eseguite l'installer esattamente come farebbe un utente, poi completate la cattura.

Due cose vale la pena farle durante l'installazione:

Avviate l'applicazione una volta prima di concludere la cattura. Molte applicazioni eseguono una configurazione al primo avvio: creano la configurazione, scrivono i valori predefiniti nel registro, scompattano risorse. Se catturate prima che questo accada, confezionate un'applicazione che non si è mai inizializzata e che eseguirà il suo primo avvio dentro il contenitore, dove la scrittura potrebbe non persistere.

Annotate tutto ciò che l'installer vi chiede. Chiavi di licenza, indirizzi dei server, percorsi di installazione. Quelle scelte sono ora incorporate nel pacchetto, e se erano sbagliate lo state ricostruendo.

Qui impostate anche l'identità del pacchetto, ed è scomoda da cambiare in seguito. Vive nel manifesto e ha questo aspetto:

<Identity Name="Contoso.LineOfBusinessApp"
          Publisher="CN=Contoso Ltd, O=Contoso Ltd, C=GB"
          Version="1.0.0.0" />

Publisher è quello che conta: deve corrispondere carattere per carattere al soggetto del vostro certificato di firma, quindi decidetelo ora anziché scoprire una discrepanza al passo quattro. Version è un numero in quattro parti e la distribuzione tiene conto che aumenti, quindi adottate una convenzione e mettetela per iscritto.

Se non c'è alcun installer, la cattura non è la vostra strada: riconfezionare senza l'installer originale copre invece quel caso.

Passo 3: aspettatevi che si comporti male, e diagnosticate per bene

Il pacchetto si installerà. Poi qualcosa non andrà.

Non iniziate ad applicare correzioni a caso. Riproducete il problema come utente standard, scoprite cosa sta davvero chiedendo l'applicazione, e associate il sintomo a una causa specifica. Abbiamo trattato quella mappatura in quale correzione PSF mi serve, e la versione breve è: verificate la directory di lavoro prima di ricorrere a qualsiasi altra cosa, perché è la causa singola più comune.

Due abitudini tengono corta la faccenda. Riproducete come utente standard, perché molte rotture MSIX segnalate sono un'assunzione sui permessi che era da sempre nell'applicazione ed era mascherata dal fatto che tutti lavoravano come amministratori locali. Poi guardate dove il contenitore ha messo la scrittura: i dati per utente finiscono sotto %LOCALAPPDATA%\Packages\<PackageFamilyName>\LocalCache, e trovare lì il file dimostra che la scrittura è riuscita e che l'applicazione sta cercando nel posto vecchio.

Applicate una modifica alla volta e ritestate. Un pacchetto che porta quattro correzioni dove ne serviva una è un pacchetto che nessuno manterrà.

Se la terza correzione non ha risolto la questione, riconsiderate la destinazione. Convertire un'applicazione legacy in MSIX copre la decisione più ampia, e non c'è nulla di male nel consegnare un'applicazione ostica per un'altra strada mentre il parco si muove.

Passo 4: firmatelo

Un MSIX non firmato non si installerà su un dispositivo gestito. Questo non è opzionale ed è il punto in cui si fermano molti primi tentativi.

Vi serve un certificato di firma del codice il cui soggetto corrisponda esattamente all'editore nel manifesto del pacchetto. Non approssimativamente. Esattamente. Una discrepanza qui produce un errore di installazione il cui messaggio non menziona affatto il certificato, ed è per questo che costa alle persone un pomeriggio. Confrontate i due direttamente prima di firmare:

Get-ChildItem Cert:\CurrentUser\My -CodeSigningCert |
  Select-Object Subject, Thumbprint, NotAfter

Qualunque cosa torni sotto Subject va nel Publisher del manifesto, compreso l'ordine dei nomi distinti relativi e la spaziatura. Copiatelo anziché digitarlo.

Firmate dall'archivio certificati tramite thumbprint anziché maneggiare un file PFX, e usate un server di timestamp RFC 3161. Senza un timestamp il pacchetto smette di superare la validazione quando il certificato scade, anche se era stato firmato legittimamente mentre il certificato era valido.

signtool sign /sha1 <thumbprint> /fd SHA256 /tr <your RFC 3161 timestamp URL> /td SHA256 .\ContosoApp.msix

Un'ultima cosa coglie impreparati con i certificati interni: il certificato deve essere attendibile sul dispositivo che installa il pacchetto. Un'autorità pubblica si aggancia già a una radice di cui Windows si fida; la vostra autorità interna o un certificato di test autofirmato no, quindi deve prima arrivare nell'archivio di attendibilità del dispositivo. Distribuitelo tramite la vostra normale gestione dei certificati anziché a mano su una macchina di test, altrimenti la vostra validazione passa sull'unico dispositivo dove avrebbe mai potuto passare.

Passo 5: validate prima di rilasciarlo

Validate il pacchetto e trattate un'uscita diversa da zero come uno stop. È molto più economico trovare un manifesto malformato adesso che dopo che ha raggiunto un anello di test.

Confermate che la firma e il timestamp siano andati a posto oltre al manifesto:

Get-AuthenticodeSignature .\ContosoApp.msix |
  Format-List Status, SignerCertificate, TimeStamperCertificate

Status dovrebbe riportare Valid e TimeStamperCertificate non dovrebbe essere vuoto. Un campo timestamp vuoto è un pacchetto che smette di installarsi a una data futura senza motivo visibile.

Poi installatelo davvero su una macchina pulita, come utente standard, e verificate:

• Si avvia.
• Mantiene le impostazioni dopo un riavvio.
• Si disinstalla in modo pulito e non lascia nulla dietro di sé.

Add-AppxPackage .\ContosoApp.msix
Get-AppxPackage -Name Contoso.LineOfBusinessApp | Select-Object Name, Version, PackageFullName
Remove-AppxPackage -Package <PackageFullName>

Quest'ultimo è il senso di MSIX. Se la disinstallazione lascia residui, qualcosa viene scritto fuori dal contenitore e non avete finito.

Aggiungete una quarta verifica se le persone tengono l'applicazione aperta tutto il giorno: installatela, avviatela, poi installate sopra una versione incrementata. Gli aggiornamenti vengono predisposti mentre l'applicazione è in esecuzione e applicati al suo avvio successivo, quindi un utente che non la chiude mai non riceve mai l'aggiornamento. Non è un bug, ma è una chiamata al supporto se nessuno se lo aspettava.

Passo 6: distribuite tramite Intune

Confezionate il MSIX per Intune e assegnatelo. Nell'interfaccia di amministrazione di Intune il percorso è Apps, All apps, Add, poi il tipo di app line-of-business, che accetta direttamente il file .msix. Assegnatelo come richiesto prima a un gruppo pilota, disponibile al gruppo più ampio una volta che il pilota ha tenuto per qualche giorno.

Vale la pena saperlo: il MSIX distribuito in questo modo si aggiorna in base alla versione, quindi il vostro schema di versionamento ora conta. Sbagliatelo una volta e i dispositivi rifiuteranno l'aggiornamento perché la versione non è aumentata. Sorvegliate lo stato di installazione per dispositivo anziché fidarvi dell'assegnazione, e tenete presente che un dispositivo che porta già una copia firmata da un editore diverso rifiuterà quella gestita, perché per Windows sono applicazioni diverse.

Dove se ne va davvero il tempo

Non nella conversione. La conversione è questione di minuti. Il tempo se ne va nella disciplina della macchina pulita, nella diagnosi quando l'applicazione si comporta male, e nella configurazione della firma. Fare una applicazione vi insegna lo schema. Farne quattrocento è un problema diverso, ed è il motivo per cui il packaging applicativo resta un mestiere specialistico.

La differenza non è lo sforzo per applicazione, è la coerenza: se ogni pacchetto sia stato catturato sulla stessa build, firmato allo stesso modo, e abbia avuto le sue decisioni sulle correzioni registrate da qualche parte che non sia la memoria di una persona sola. Questo è un problema di flusso di lavoro anziché di packaging, ed è il motivo per cui i parchi finiscono con una cartella di pacchetti che nessuno osa ricostruire.

Dove si inserisce EtherApps Forge

EtherApps Forge è costruito per il caso dei quattrocento: cattura, instradamento, predisposizione delle correzioni, firma e validazione come un unico flusso anziché sei strumenti e un manuale operativo. Le decisioni vengono registrate insieme al pacchetto invece che ricordate, ed è ciò che rende il secondo passaggio su un parco più economico del primo.

È un'applicazione desktop per Windows anziché un servizio ospitato, quindi cattura e firma restano dentro il vostro ambiente, e funziona con una prova gratuita di 7 giorni. Se distribuite le vostre build anziché catturare l'installer di qualcun altro, il percorso parte invece da una cartella di build: packaging MSIX per sviluppatori e ISV lo copre, e creare e firmare MSIX in CI/CD senza il Windows SDK mostra la forma della pipeline. Per la visione a livello di parco, packaging e distribuzione MSIX va dalla cattura alla consegna.

Esplora il packaging e distribuzione MSIX per vedere come cattura, rimedio, firma e consegna funzionano come un unico flusso anziché sei.