Conoscere il programma di installazione

Questo articolo elenca le informazioni necessarie prima di convertire il programma di installazione esistente in msiX. Potrebbe non essere necessario eseguire molte operazioni per preparare l'applicazione per il processo di creazione del pacchetto, ma se uno degli elementi seguenti si applica all'applicazione, è necessario risolverlo prima della creazione del pacchetto.

• L'applicazione ha un servizio. È supportata la conversione di applicazioni con servizi, ma è importante tenere presenti le limitazioni per la conversione di un servizio. Dopo la conversione, sarà necessaria l'elevazione dei privilegi di amministratore per installare MSIX che contiene un servizio. È possibile convertire un'applicazione con servizi a partire dalla versione 1.2019.1220.0 di MSIX Packaging Tool ed è possibile distribuire MSIX con i servizi a partire dalla versione spring 2020 di Windows 10.

• Il programma di installazione richiede un riavvio. Se il programma di installazione richiede un riavvio, questo è supportato in MSIX Packaging Tool a partire dalla versione 1.2019.701.0. Se il programma di installazione restituisce un codice di uscita non comune per indicare che è necessario un riavvio, è necessario aggiungerlo alla sezione codici di uscita di riavvio delle impostazioni di MSIX Packaging Tool.

• L'applicazione .NET richiede una versione di .NET Framework precedente la 4.6.2. Se stai creando un pacchetto di un'applicazione .NET, ti consigliamo di scegliere .NET Framework 4.6.2 o versione successiva come destinazione dell'applicazione. La possibilità di installare ed eseguire applicazioni desktop in pacchetto è stata introdotta per la prima volta in Windows 10, versione 1607 (denominata anche Aggiornamento dell'anniversario) e questa versione del sistema operativo include .NET Framework 4.6.2 per impostazione predefinita. Le versioni successive del sistema operativo includono versioni più recenti di .NET Framework. Per un elenco completo delle versioni di .NET incluse nelle versioni successive di Windows 10, vedi questo articolo.

  L'uso di versioni di .NET Framework precedenti la 4.6.2 come destinazione delle applicazioni desktop in pacchetto dovrebbe funzionare nella maggior parte dei casi. Se tuttavia scegli come destinazione una versione precedente la 4.6.2, dovresti eseguire un test completo dell'applicazione desktop in pacchetto prima di distribuirla agli utenti.

  • 4.0 - 4.6.1: le applicazioni destinate a queste versioni di .NET Framework devono essere eseguite senza problemi nella versione 4.6.2 o successiva. Dovrebbe quindi essere possibile installare ed eseguire queste applicazioni senza modifiche in Windows 10, versione 1607 o successive, con la versione di .NET Framework inclusa nel sistema operativo.

  • 2.0 e 3.5: nei test, le applicazioni desktop in pacchetto destinate a queste versioni di .NET Framework funzionano in genere, ma possono presentare problemi di prestazioni in alcuni scenari. Per l'installazione e l'esecuzione di queste applicazioni in pacchetto, è necessario che nel computer di destinazione sia installata la funzionalità .NET Framework 3.5, che include anche .NET Framework 2.0 e 3.0. Ti consigliamo inoltre di testare accuratamente queste applicazioni dopo averne creato il pacchetto.

• L'applicazione richiede un driver. MSIX non supporta i driver.

• L'applicazione scrive nella cartella AppData o nel Registro di sistema con l'intenzione di condividere dati con un'altra app. Dopo la conversione, la cartella AppData viene reindirizzata all'archivio dati locali dell'app, che consiste in un archivio privato per ogni app.

  Tutte le voci che l'applicazione scrive nell'hive del Registro di sistema HKEY_LOCAL_MACHINE vengono reindirizzate a un file binario isolato e le eventuali voci che l'applicazione scrive nell'hive del Registro di sistema HKEY_CURRENT_USER vengono inserite in un percorso privato, per singolo utente e singola app. Per altre informazioni sul reindirizzamento dei file e del Registro di sistema, vedi Informazioni sul funzionamento di Desktop Bridge.

• L'applicazione scrive nella relativa directory di installazione. Ad esempio, l'applicazione scrive in un file di log che inserisci nella stessa directory del file con estensione exe. Questa operazione non è supportata perché la cartella è protetta. È consigliabile scrivere in un'altra posizione, ad esempio l'archivio dati dell'app locale. È stata aggiunta una funzionalità che consente di eseguire questa operazione nel 1809 e versioni successive.

• L'applicazione usa la directory di lavoro corrente. In fase di esecuzione, la tua applicazione desktop in pacchetto non avrà a disposizione la stessa directory di lavoro specificata in precedenza nel collegamento LNK del desktop. Devi modificare la directory di lavoro corrente in fase di esecuzione se la disponibilità della directory corretta è importante per il corretto funzionamento della tua applicazione.

• L'applicazione installa e carica assembly dalla cartella affiancata di Windows. Ad esempio, l'applicazione usa librerie di runtime C VC8 o VC9 e le collega dinamicamente dalla cartella side-by-side di Windows, ovvero il codice usa i file DLL comuni da una cartella condivisa, ad esempio C:\Windows\WinSxS. Questo non è supportato. Sarà necessario collegarli in modo statico collegandoli ai file di libreria ridistribuibili direttamente nel codice.

Altre considerazioni

• Ricomprimere il programma di installazione nell'architettura corretta. Se il programma di installazione deve essere installato in un computer x86. Assicurarsi di creare nuovamente il pacchetto di installazione in un computer x86. Questo è applicabile per il programma di installazione destinato ai computer x64.

  Nota

  Se l'applicazione deve scrivere nella directory di installazione o usare la directory di lavoro corrente, puoi anche valutare l'opportunità di aggiungere al pacchetto una correzione del runtime usando il Package Support Framework. Per altre informazioni, vedi questo articolo.