Da App-V a MSIX: le quattro cose che si rompono sempre

Convertire pacchetti App-V in MSIX è per lo più meccanico, finché non lo è più. Quattro cose spiegano la stragrande maggioranza delle segnalazioni del tipo «si è convertita bene e ora si comporta in modo strano», e sono le stesse quattro ogni volta.

Vale la pena conoscerle prima di iniziare, perché ciascuna costa poco da gestire deliberatamente e molto da scoprire in un anello di test.

Il motivo di fondo è lo stesso in tutti e quattro i casi: App-V virtualizzava cose che App-V controllava, e MSIX le racchiude in modo diverso. Tutto ciò per cui l'applicazione contava su App-V ha bisogno di una nuova risposta. Nulla di questo è un difetto di MSIX. I due formati tracciano in punti diversi la linea fra pacchetto e ambiente, e una conversione non porta con sé ciò che cade fuori da quella linea.

Aprite il pacchetto prima di convertirlo

Un pacchetto App-V 5 non è opaco. Il file .appv è un contenitore OPC, in pratica un file zip con dentro un manifesto, quindi tutto ciò che vi serve è leggibile prima che uno strumento di conversione lo tocchi.

Tre file portano il comportamento:

• AppxManifest.xml, dentro il .appv, contiene i valori predefiniti prodotti quando l'applicazione è stata sequenziata.
• <PackageName>_DeploymentConfig.xml porta le impostazioni a livello di macchina e gli script in contesto macchina.
• <PackageName>_UserConfig.xml porta le impostazioni per utente e gli script in contesto utente.

La precedenza va da UserConfig a DeploymentConfig al manifesto, quindi un'impostazione può comparire in tutti e tre con tre valori diversi e solo uno è attivo. Leggete solo il manifesto e vi perdete le personalizzazioni che qualcuno ha aggiunto in seguito per far funzionare l'applicazione, che sono proprio quelle con più probabilità di essere portanti.

Estrarli richiede pochi secondi:

Copy-Item .\LineOfBusinessApp.appv .\LineOfBusinessApp.zip
Expand-Archive .\LineOfBusinessApp.zip -DestinationPath .\LineOfBusinessApp
Select-Xml -Path .\LineOfBusinessApp\AppxManifest.xml -XPath '//*[local-name()="EnvironmentVariables" or local-name()="Shortcut" or local-name()="FileTypeAssociation"]' | ForEach-Object { $_.Node.OuterXml }

Leggete prima tutte e tre le sorgenti di configurazione, poi indirizzate ogni rilevazione dove ora le compete.

1. Variabili d'ambiente

App-V vi permetteva di definire variabili d'ambiente come parte del pacchetto, e l'applicazione le vedeva dentro il suo ambiente virtuale. Risiedono in un sottosistema <EnvironmentVariables>, e uno qualsiasi dei due file di configurazione può aggiungerne o eliminarne:

<EnvironmentVariables Enabled="true">
  <Include>
    <Variable Name="LOBAPP_DATA" Value="%UserProfile%\LineOfBusinessApp" />
  </Include>
</EnvironmentVariables>

MSIX gestisce la cosa in modo diverso, e le variabili che avevate dichiarato in App-V non arrivano automaticamente. Un'applicazione che legge una variabile per trovare un percorso dati, un nome di server o la posizione di una licenza si avvia e poi si comporta come se non fosse mai stata configurata. Funziona, semplicemente non sa nulla.

Che cosa fare: enumerate le variabili dichiarate dal pacchetto prima di convertire. È il passo che si salta, perché le variabili non sono visibili nella configurazione dell'applicazione. Poi decidete per ciascuna se diventi una variabile a livello macchina o utente impostata dai vostri strumenti di distribuzione, un valore in un file di configurazione che l'applicazione legge, o qualcosa che uno script di avvio imposta prima che l'eseguibile parta.

La firma di fallimento è un'applicazione che si avvia in modo pulito e poi si lamenta di un server o di un percorso mancante. Attenzione alla variante più silenziosa, in cui ripiega su un valore predefinito interno anziché dare errore, perché quella emerge settimane dopo con i dati nel posto sbagliato.

2. Collegamenti

I pacchetti App-V portavano per intero le loro definizioni dei collegamenti. L'elemento <Shortcut> nomina il .lnk da creare, il suo <Target>, <Icon>, <Arguments>, <WorkingDirectory> e <Description>, così un pacchetto sequenziato riproduceva ciò che l'installer aveva messo nel menu Start.

MSIX genera invece la propria voce dal manifesto del pacchetto, e il risultato non è sempre quello che produceva App-V. Le lamentele abituali: il collegamento finisce altrove, l'icona è sbagliata o assente, oppure gli argomenti da riga di comando sono spariti.

Quest'ultima è quella pericolosa. Se il collegamento App-V passava un argomento che metteva l'applicazione in una modalità particolare e la voce MSIX non lo fa, gli utenti si ritrovano un'applicazione che si apre nello stato sbagliato anziché una che fallisce in modo visibile. I parchi che pubblicano la stessa applicazione due volte, come «Finanza» e come «Sola lettura», con la differenza affidata interamente a uno switch, sono più comuni di quanto vorreste.

Che cosa fare: catturate la definizione completa del collegamento, argomenti e directory di lavoro compresi, e riproducetela deliberatamente. Dove un argomento distingue davvero due modi di eseguire l'applicazione, di solito questo diventa due voci applicative nel manifesto anziché una.

Controllate in particolare la directory di lavoro. Se nulla la imposta, Windows usa la directory System32 come directory di lavoro di un'applicazione confezionata, ed è per questo che «non trova i propri file» è un primo sintomo così comune. Il Package Support Framework la imposta esplicitamente con un valore workingDirectory in config.json, ed è la correzione applicata più di frequente dopo qualsiasi conversione. Quale correzione PSF mi serve mappa le altre.

3. Script

Questa è la differenza singola più grande e quella che fa deragliare le migrazioni.

App-V supportava script in otto punti del ciclo di vita, il che spiega quanta logica un parco accumuli senza che nessuno la tenga tracciata:

I parchi che eseguono App-V da anni hanno spesso logica reale in quegli script: mappare un'unità, recuperare configurazione, ripulire una posizione temporanea, registrare qualcosa. Più script possono agganciarsi a un solo trigger tramite ScriptRunner.exe, quindi una singola voce AddPackage può eseguire quattro cose in sequenza con i propri timeout e comportamenti di rollback.

MSIX non offre gli stessi agganci per gli script del ciclo di vita. L'equivalente più vicino è il Package Support Framework, che esegue uno script PowerShell prima di un eseguibile confezionato e uno dopo la sua uscita, impostati per eseguibile come startScript e endScript in config.json.

Questo copre StartProcess e ExitProcess. Non copre gli altri sei. Tutto ciò che veniva eseguito ad aggiunta, pubblicazione, rimozione dalla pubblicazione o rimozione si sposta nei vostri strumenti di distribuzione, perché ora sono l'unica cosa che sa quando un pacchetto arriva o se ne va.

Che cosa fare: trovate gli script prima di convertire, e leggeteli. Alcuni diventano comportamento di installazione o disinstallazione in Intune o Configuration Manager. Alcuni diventano uno script di avvio nel pacchetto. Alcuni diventano logica nella configurazione dell'applicazione. Alcuni si rivelano un doppione di ciò che la piattaforma moderna fa nativamente, e si possono cancellare con sollievo.

Due note pratiche se prendete quella strada. L'esecuzione degli script richiede che i criteri di esecuzione di PowerShell siano impostati su RemoteSigned sia per l'host a 64 bit sia per quello a 32 bit. E StartingScriptWrapper.ps1 deve trovarsi nel pacchetto accanto all'eseguibile, altrimenti non viene eseguito nulla e nulla spiega il perché.

La firma di fallimento qui è la peggiore delle quattro, perché l'applicazione funziona perfettamente per chi la sta testando, la cui unità era già mappata.

4. Associazioni dei tipi di file

App-V registrava le associazioni dentro il suo ambiente virtuale con un certo dettaglio: l'estensione, il suo ProgId, i nomi descrittivi e i comandi della shell con le proprie righe di comando, così un verbo «Modifica» del tasto destro poteva avviare l'eseguibile con uno switch diverso da «Apri».

MSIX le dichiara nel manifesto come estensione, e la dichiarazione deve essere corretta:

<uap:Extension Category="windows.fileTypeAssociation">
  <uap:FileTypeAssociation Name="lobdoc">
    <uap:SupportedFileTypes>
      <uap:FileType>.lob</uap:FileType>
    </uap:SupportedFileTypes>
  </uap:FileTypeAssociation>
</uap:Extension>

Quattro cose vanno storte, più o meno in questo ordine di frequenza.

L'associazione non è dichiarata affatto, quindi il doppio clic su un file non fa nulla di utile.

È dichiarata ma Windows non la onora, perché un'altra applicazione possiede già quell'estensione e la scelta dell'utente ha la priorità. Questa è quella fastidiosa: funziona sulla macchina di packaging e non sul dispositivo di un utente reale.

Il Name è sbagliato. Deve essere in minuscolo e dovrebbe restare stabile fra un aggiornamento e l'altro, perché è l'identificatore sotto cui Windows raggruppa i tipi di file.

L'estensione è riservata. Windows tiene un insieme di estensioni e schemi URI per le applicazioni integrate e per il sistema operativo, e una registrazione su una di quelle viene ignorata anziché rifiutata, quindi sembra che la dichiarazione semplicemente non abbia preso.

I verbi personalizzati sono la parte che si dimentica. I comandi della shell oltre a un semplice apri non sopravvivono al viaggio e vanno ricostruiti apposta.

Che cosa fare: elencate le estensioni registrate dal pacchetto, con i loro valori ProgId e gli eventuali comandi della shell, dichiaratele nel manifesto e testate su un dispositivo che abbia le applicazioni che ha un utente reale. Non una macchina virtuale pulita, che per definizione non ha rivendicazioni concorrenti.

Già che ci siete, annotate i protocolli URL, gli AppPaths, le registrazioni dei software client e le impostazioni COM che gli stessi file portano. Si rompono meno spesso, ma un gestore lobapp:// che ha smesso silenziosamente di esistere è un ticket che confonde.

L'ordine che fa risparmiare tempo

Fate tutta la scoperta prima di convertire qualsiasi cosa:

1. Estraete le variabili d'ambiente dichiarate dal pacchetto, da tutte e tre le sorgenti.
2. Estraete le definizioni dei collegamenti, argomenti e directory di lavoro compresi.
3. Estraete e leggete gli script, annotando a quale trigger ciascuno si aggancia.
4. Elencate le associazioni dei tipi di file, i loro valori ProgId e i loro comandi della shell.
5. Annotate i sottosistemi rimanenti: protocolli URL, AppPaths, software client, COM.

Registrate la decisione accanto a ogni rilevazione, non solo la rilevazione. «Imposta LOBAPP_DATA» è una nota. «Imposta LOBAPP_DATA, diventa una variabile utente nella distribuzione Intune» è un piano, e la differenza sta nel fatto che il prossimo packager debba ricavarlo di nuovo.

Al massimo è un'ora per applicazione, e trasforma la conversione da esercizio di scoperta in esercizio di implementazione. Saltatela e troverete ciascuno di questi punti singolarmente, in un anello di test, con un utente che segnala il sintomo anziché la causa.

Ecco che cosa vi compra quell'ora. Un'applicazione per la finanza si converte in modo pulito, poi nel pilota emergono due cose: non trova i propri modelli, perché il pacchetto impostava una variabile che puntava a una condivisione e ora nulla la imposta, e metà del gruppo la apre nella modalità sbagliata, perché il collegamento App-V passava uno switch di sola lettura. Entrambe erano nel file _DeploymentConfig.xml prima che chiunque convertisse alcunché.

Poi convertite, e testate come utente standard su un dispositivo che assomigli a uno reale.

Dove si inserisce tutto questo

Il percorso di migrazione più ampio, compreso quali pacchetti debbano diventare MSIX, è in migrazione da App-V a MSIX. Vale la pena leggerlo insieme a App-V Server finisce, App-V no, perché la tempistica è meno urgente di quanto suggerisse la maggior parte della copertura e affrettare queste conversioni è il modo in cui i quattro problemi qui sopra arrivano in produzione.

Se l'applicazione si comporta male in modi che questi quattro punti non spiegano, conversione da legacy a MSIX copre i comportamenti del contenitore che riguardano applicazioni mai passate da App-V.

Dove si inserisce EtherApps Forge

EtherApps Forge cattura le applicazioni da ambienti più datati e prepara la remediation come parte del packaging anziché come progetto separato successivo, così la correzione della directory di lavoro, il reindirizzamento dei file e lo script di avvio vengono decisi mentre il pacchetto viene costruito anziché dopo il fallimento di un pilota.

EtherApps Forge è un'applicazione desktop per Windows con una prova gratuita di 7 giorni, non un servizio ospitato, quindi la cattura e l'output restano entrambi dentro il vostro ambiente. Il percorso app legacy copre scoperta e remediation, packaging e distribuzione MSIX copre firma, validazione e consegna, e modernizzazione e migrazione delle applicazioni copre la decisione su quali applicazioni prendano questa strada.

Esplora la modernizzazione delle applicazioni legacy

Rispondete alle quattro domande prima di convertire, e la conversione smette di produrre sorprese.