Prepararsi per la creazione del pacchetto di un'applicazione desktop

In questo articolo sono elencate le informazioni che devi conoscere prima di creare un pacchetto della tua applicazione desktop. Per preparare la tua applicazione per la creazione del pacchetto potrebbero non essere necessarie molte operazioni, ma se una qualsiasi delle considerazioni seguenti è applicabile alla tua applicazione, segui le indicazioni suggerite prima di creare il pacchetto.

• 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.

  • Da 4.0 a 4.6.1: le applicazioni destinate a queste versioni di .NET Framework dovrebbero essere eseguite senza problemi nella versione 4.6.2 o successive. 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: in base ai nostri test, le applicazioni desktop in pacchetto destinate a queste versioni di .NET Framework normalmente funzionano 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 viene sempre eseguita con privilegi di sicurezza elevati. L'applicazione deve funzionare se eseguita con i privilegi di utente interattivo. Gli utenti che installano l'applicazione potrebbero non essere amministratori di sistema, quindi il requisito di esecuzione con privilegi elevati implica che l'applicazione non funzionerà correttamente per gli utenti standard. Se prevedi di pubblicare la tua app in Microsoft Store, tieni presente che le app che richiedono l'elevazione dei privilegi per una qualsiasi funzionalità non vengono accettate nello Store.

• L'applicazione richiede un driver in modalità kernel o un servizio di Windows. MSIX non supporta un driver in modalità kernel o un servizio di Windows che deve essere eseguito con un account di sistema. Invece di un servizio di Windows, usa un'attività in background.

• I moduli della tua app vengono caricati in-process in processi che non sono inclusi nel tuo pacchetto dell'app di Windows. Questa situazione non è consentita e ciò significa che le estensioni in-process, come le estensioni della shell, non sono supportate. Se però hai due app nello stesso pacchetto, puoi usare le comunicazioni tra processi tra di esse.

• Verifica che le estensioni installate dall'applicazione vengano inserite nello stesso percorso di installazione dell'applicazione. Windows consente agli utenti e ai responsabili IT di modificare il percorso di installazione predefinito per i pacchetti. Vedere "Impostazioni-System-Archiviazione-More>>> Archiviazione Impostazioni- Change where new content is save to ->> New Apps will save to". Se stai installando un'estensione con l'applicazione, verifica che l'estensione non preveda restrizioni aggiuntive per la cartella di installazione. Per alcune estensioni, ad esempio, può essere disabilitata l'installazione nelle unità non di sistema. Se il percorso predefinito è stato modificato, verrà generato un errore 0x80073D01 (ERROR_DEPLOYMENT_BLOCKED_BY_POLICY).

• L'applicazione usa un ID modello utente applicazione (AUMID) personalizzato. Se il processo chiama SetCurrentProcessExplicitAppUserModelID per impostare il proprio AUMID, può usare solo l'AUMID generato per il processo dall'ambiente del modello di applicazione o dal pacchetto dell'app di Windows. Non puoi definire AUMID personalizzati.

• L'applicazione modifica l'hive del Registro di sistema HKEY_LOCAL_MACHINE (HKLM) . Qualsiasi tentativo eseguito dalla tua applicazione per creare una chiave HKLM o aprirne una per la modifica avrà come risultato un errore di accesso negato. Ricorda che l'applicazione usa una specifica visualizzazione virtualizzata privata del Registro di sistema, quindi il concetto di hive del Registro di sistema a livello di utente e di computer (come è il caso di HKLM) non è applicabile. Dovrai trovare un altro modo per ottenere quello per cui usavi HKLM, ad esempio la scrittura in HKEY_CURRENT_USER (HKCU).

• L'applicazione usa una sottochiave del Registro di sistema ddeexec per avviare un'altra app. Usa invece uno dei gestori di verbo DelegateExecute nella configurazione implementata dalle varie estensioni Activatable* nel manifesto del pacchetto della tua app.

• 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.

  Usa altri mezzi per la condivisione dei dati tra processi. Per altre info, vedi Archiviazione e recupero di impostazioni e altri dati dell'app.

• 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 situazione non è supportata, quindi dovrai trovare un'altra posizione, come l'archivio dati locale dell'app.

• 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.

  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.

• L'installazione dell'applicazione richiede l'interazione dell'utente. Il programma di installazione della tua applicazione deve poter essere eseguito in modo invisibile all'utente e provvedere all'installazione di tutti i prerequisiti non disponibili per impostazione predefinita in un'immagine pulita del sistema operativo.

• L'applicazione espone oggetti COM. I processi e le estensioni dall'interno del pacchetto possono registrare e usare server OLE COM & , sia in-process che out-of-process (OOP). Creators Update aggiunge il supporto COM packaged che offre la possibilità di registrare i server OLE COM & OOP ora visibili all'esterno del pacchetto. Vedi la pagina relativa al supporto del server COM e del documento OLE per Desktop Bridge.

  Il supporto COM in pacchetto funziona con le API COM esistenti, ma non funzionerà per le estensioni dell'applicazione che si basano direttamente sulla lettura del Registro di sistema, poiché la posizione per il modello COM in pacchetto è privata.

• L'applicazione espone assembly GAC per l'uso in altri processi. La tua applicazione non può esporre assembly GAC per l'uso in processi originati da file eseguibili esterni al tuo pacchetto dell'app di Windows. I processi interni al pacchetto possono registrare e usare assembly GAC come di consueto, ma questi non saranno visibili esternamente. Questo significa che gli scenari di interoperabilità come OLE non funzioneranno se richiamati da processi esterni.

• L'applicazione si collega a librerie di runtime C (CRT) in modo non supportato. La libreria di runtime C/C++ di Microsoft fornisce routine per la programmazione per il sistema operativo Microsoft Windows. Queste routine automatizzano molte attività di programmazione comuni non fornite dai linguaggi C e C++. Se la tua applicazione usa la libreria di runtime C/C++, devi assicurarti che sia collegata in modo supportato.

  Visual Studio 2017 supporta sia il collegamento dinamico, per consentire al codice di usare file DLL comuni, sia il collegamento statico, per collegare la libreria direttamente nel tuo codice, alla versione corrente di CRT. Se possibile, ti consigliamo di usare per l'applicazione il collegamento dinamico con Visual Studio 2017.

  Il supporto nelle versioni precedenti di Visual Studio è variabile. Per altri dettagli, vedi la tabella seguente:

  Versione di Visual Studio	Collegamento dinamico	Collegamento statico
  2005 (VC 8)	Non supportato	Funzionalità supportata
  2008 (VC 9)	Non supportato	Funzionalità supportata
  2010 (VC 10)	Funzionalità supportata	Funzionalità supportata
  2012 (VC 11)	Funzionalità supportata	Non supportato
  2013 (VC 12)	Funzionalità supportata	Non supportato
  2015 e 2017 (VC 14)	Funzionalità supportata	Funzionalità supportata

  Nota: in tutti i casi, devi impostare il collegamento alla versione di CRT più recente disponibile pubblicamente.

• L'applicazione installa e carica assembly dalla cartella affiancata di Windows. Ad esempio, la tua applicazione usa librerie di runtime C VC8 o VC9 con collegamento dinamico dalla cartella affiancata di Windows e questo significa che il codice usa i file DLL comuni da una cartella condivisa. Questo non è supportato. Dovrai usare un link statico ai file delle librerie ridistribuibili direttamente nel codice.

• L'applicazione usa una dipendenza nella cartella System32/SysWOW64. Per fare in modo che le DLL funzionino, devi includerle nella parte del file system virtuale del pacchetto dell'app di Windows. In questo modo, l'applicazione si comporterà come se le DLL fossero installate nella cartella System32/SysWOW64. Nella radice del pacchetto crea una cartella denominata VFS. All'interno di tale cartella crea una cartella SystemX64 e una SystemX86. Inserisci quindi la versione a 32 bit della DLL nella cartella SystemX86 e la versione a 64 bit nella cartella SystemX64.

• L'applicazione usa un pacchetto framework VCLibs. Se stai convertendo un'app Win32 C++, devi gestire la distribuzione del runtime di Visual C++. Visual Studio 2019 e Windows SDK includono i pacchetti framework più recenti per le versioni 11.0, 12.0 e 14.0 del runtime di Visual C++ nelle cartelle seguenti:

  • Pacchetti framework VC 14.0: C:\Programmi (x86)\Microsoft SDKs\Windows Kits\10\ExtensionSDKs\Microsoft.VCLibs.Desktop\14.0

  • Pacchetti framework VC 12.0: C:\Programmi (x86)\Microsoft SDKs\Windows Kits\10\ExtensionSDKs\Microsoft.VCLibs.Desktop.120\14.0

  • Pacchetti framework VC 11.0: C:\Programmi (x86)\Microsoft SDKs\Windows Kits\10\ExtensionSDKs\Microsoft.VCLibs.Desktop.110\14.0

  Per usare uno di questi pacchetti, devi fare riferimento al pacchetto come dipendenza nel manifesto del pacchetto. Quando i clienti installano la versione finale dell'app da Microsoft Store, il pacchetto verrà installato dallo Store insieme all'app. Se trasferisci l'app localmente, le dipendenze non vengono installate. Per installare manualmente le dipendenze, devi installare il pacchetto framework appropriato usando il pacchetto con estensione appx appropriato per x86, x64 o ARM, che si trova nelle cartelle di installazione elencate in precedenza.

  Per includere nell'app un riferimento a un pacchetto framework del runtime di Visual C++:

  1. Passa alla cartella di installazione del pacchetto framework sopra indicata per la versione del runtime di Visual C++ usata dall'app.

  2. Apri il file SDKManifest.xml nella cartella, individua l'attributo FrameworkIdentity-Debug o FrameworkIdentity-Retail (a seconda che usi la versione di debug o la versione finale del runtime) e copia i valori Name e MinVersion da tale attributo. Ecco ad esempio l'attributo FrameworkIdentity-Retail per il pacchetto framework VC 14.0 corrente.

     FrameworkIdentity-Retail = "Name = Microsoft.VCLibs.140.00.UWPDesktop, MinVersion = 14.0.27323.0, Publisher = 'CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US'"
     

  3. Nel manifesto del pacchetto per l'app aggiungi l'elemento <PackageDependency> seguente nel nodo <Dependencies>. Assicurati di sostituire i valori Name e MinVersion con quelli copiati nel passaggio precedente. L'esempio seguente specifica una dipendenza per la versione corrente del pacchetto framework VC 14.0.

     <PackageDependency Name="Microsoft.VCLibs.140.00.UWPDesktop" MinVersion="14.0.27323.0" Publisher="CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US" />
     

• L'applicazione contiene una jump list personalizzata. Occorre considerare diversi problemi e aspetti relativi ai casi in cui vengono usate le jump list.

  • L'architettura dell'applicazione non corrisponde al sistema operativo. Le jump list attualmente non funzionano correttamente se l'applicazione e le architetture del sistema operativo non corrispondono (ad esempio un'applicazione x86 in esecuzione su Windows x64). In questo momento, l'unica soluzione consiste nel ricompilare l'applicazione per l'architettura corrispondente.

  • L'applicazione crea voci di jump list e chiama ICustomDestinationList::SetAppID o SetCurrentProcessExplicitAppUserModelID . Non impostare a livello di codice l'AppID nel codice. Altrimenti le voci di jump list non vengono visualizzate. Se la tua applicazione richiede un ID personalizzato, specificalo usando il file manifesto. Per istruzioni, vedi Creare il pacchetto di un'applicazione desktop manualmente. L'AppID dell'applicazione è specificato nella sezione YOUR_PRAID_HERE.

  • L'applicazione aggiunge un collegamento shell alla jump list che fa riferimento a un eseguibile nel tuo pacchetto. Non è possibile lanciare direttamente eseguibili nel pacchetto da una jump list (a eccezione del percorso assoluto dell'eseguibile (.exe) di un'applicazione). In alternativa, registra un alias di esecuzione dell'applicazione (che consente di avviare la tua applicazione desktop in pacchetto tramite una parola chiave come se fosse in PATH) e imposta il percorso di destinazione del link sull'alias. Per informazioni dettagliate su come usare l'estensione appExecutionAlias, vedi Integrare l'app desktop con Windows 10. Notare che se sono necessari asset del collegamento nella jump list per la corrispondenza al file .exe originale, sarà necessario impostare gli asset come l'icona che utilizza SetIconLocation e il nome di visualizzazione con PKEY_Title come per altre voci personalizzate.

  • L'applicazione aggiunge delle voci alla jump list che fanno riferimento agli asset nel pacchetto dell'app mediante percorsi assoluti. Il percorso di installazione di un'applicazione può cambiare quando vengono aggiornati i pacchetti, modificando la posizione degli asset (come le icone, i documenti, l'eseguibile e così via). Se le voci della jump list fanno riferimento agli asset mediante percorsi assoluti, l'applicazione deve aggiornare la jump list periodicamente (ad esempio all'avvio) per assicurare la risoluzione corretta dei percorsi. In alternativa, utilizza le API UWP Windows.UI.StartScreen.JumpList che consentono di fare riferimento ad asset di immagini e stringhe utilizzando lo schema URI di tipo ms-resource correlato al pacchetto (che è anche sensibile al linguaggio, al DPI e al contrasto elevato).

• L'applicazione avvia un'utilità per eseguire le attività. Evita di avviare utilità di comando, ad esempio PowerShell e Cmd.exe. Se gli utenti installano la tua applicazione in un sistema che esegue Windows 10 S, l'applicazione non sarà in grado di avviare tali utilità. Questo può bloccare l'invio dell'applicazione in Microsoft Store perché tutte le app inviate in Microsoft Store devono essere compatibili con Windows 10 S.

  L'avvio di un'utilità rappresenta spesso un modo pratico per ottenere informazioni dal sistema operativo oppure per accedere al Registro di sistema o alle funzionalità del sistema. Puoi tuttavia usare in alternativa le API della piattaforma UWP per eseguire questi tipi di attività. Queste API sono più efficienti perché non necessitano di un eseguibile separato per l'esecuzione, ma soprattutto evitano l'uscita dell'applicazione dal pacchetto. In questo modo, la progettazione dell'applicazione rimane coerente con l'isolamento, l'attendibilità e la sicurezza che contraddistinguono un'applicazione inserita in un pacchetto e la tua applicazione funzionerà come previsto nei sistemi che eseguono Windows 10 S.

• L'applicazione ospita plug-in, componenti aggiuntivi o estensioni. In molti casi, le estensioni di tipo COM continueranno probabilmente a funzionare, purché l'estensione non sia in pacchetto e venga installata con attendibilità totale. Questo avviene perché tali programmi di installazione possono usare le funzionalità di attendibilità per modificare il Registro di sistema e posizionare i file di estensione ovunque l'applicazione host si aspetti di trovarli.

  Se tuttavia queste estensioni sono in pacchetto e, successivamente, vengono installate come un pacchetto di app di Windows, non funzioneranno perché ogni pacchetto (l'applicazione host e l'estensione) sarà isolato dall'altro. Per altre informazioni sul modo in cui le applicazioni sono isolate dal sistema, vedi Informazioni sul funzionamento di Desktop Bridge.

  Tutte le applicazioni e le estensioni che gli utenti installano in un sistema che esegue Windows 10 S devono essere installate come pacchetti di app di Windows. Se pertanto intendi creare un pacchetto delle estensioni o prevedi di incoraggiare i tuoi collaboratori a creare pacchetti, esamina in che modo puoi facilitare la comunicazione tra il pacchetto dell'applicazione host e i pacchetti delle estensioni. Un modo per eseguire questa operazione consiste nell'usare un servizio app.

• L'applicazione genera codice. La tua applicazione può generare codice che utilizza in memoria, ma evita di scrivere il codice generato sul disco perché il processo di certificazione app Windows non è in grado di convalidare tale codice prima dell'invio dell'applicazione. Inoltre, le app che scrivono codice sul disco non vengono eseguite correttamente nei sistemi con Windows 10 S. Questo potrebbe bloccare l'invio dell'applicazione in Microsoft Store perché tutte le app inviate in Microsoft Store devono essere compatibili con Windows 10 S.

Importante

Dopo aver creato il pacchetto dell'app di Windows, esegui il test della tua applicazione per verificare che funzioni correttamente sui sistemi che eseguono Windows 10 S. Tutte le app inviate a Microsoft Store devono essere compatibili con Windows 10 S. Le app non compatibili non verranno accettate nello Store. Vedi Testare l'app di Windows per Windows 10 S.