Preparare il pacchetto di un'applicazione desktop

Questo articolo elenca le informazioni necessarie prima di creare un pacchetto dell'applicazione desktop. 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 .NET richiede una versione di .NET Framework precedente alla 4.6.2. Se si crea un pacchetto di un'applicazione .NET, è consigliabile che l'applicazione prenda di mira .NET Framework 4.6.2 o una versione successiva. La possibilità di installare ed eseguire applicazioni desktop in pacchetto è stata introdotta per la prima volta in Windows 10, versione 1607 (chiamata 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 successive di .NET Framework. Per un elenco completo delle versioni di .NET incluse nelle versioni successive di Windows 10, vedere questo articolo.

  La destinazione delle versioni di .NET Framework precedenti alla 4.6.2 nelle applicazioni desktop in pacchetto dovrebbe funzionare nella maggior parte dei casi. Tuttavia, se si usa una versione precedente alla 4.6.2, è necessario testare completamente l'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. Pertanto, queste applicazioni devono essere installate ed eseguite senza modifiche in Windows 10, versione 1607 o successiva 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 consentire l'installazione e l'esecuzione di queste applicazioni in pacchetto, è necessario installare la funzionalità .NET Framework 3.5 nel computer di destinazione. Questa funzionalità include anche .NET Framework 2.0 e 3.0. È anche consigliabile testare queste applicazioni accuratamente dopo averle incluse nel pacchetto.

• L'applicazione viene sempre eseguita con privilegi di sicurezza elevati. L'applicazione deve funzionare durante l'esecuzione come utente interattivo. Gli utenti che installano l'applicazione potrebbero non essere amministratori di sistema, quindi richiedere che l'applicazione venga eseguita con privilegi elevati significa che non verrà eseguita correttamente per gli utenti standard. Se prevedi di pubblicare l'app in Microsoft Store, le app che richiedono l'elevazione dei privilegi per qualsiasi parte della loro funzionalità non verranno accettate nello Store.

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

• L'applicazione richiede un servizio Windows utente. MSIX non supporta i servizi Windows per utente. MSIX supporta i servizi session-0 (per macchina) in esecuzione con uno degli account di sistema definiti (LocalSystem, LocalService o NetworkService). Anziché un servizio Windows utente, usare un'attività in background.

• I moduli dell'app vengono caricati nell'ambito di processi che non fanno parte del pacchetto dell'app di Windows. Ciò non è consentito, il che significa che le estensioni in-process, come le estensioni della shell, non sono supportate. Tuttavia, se si dispone di due app nello stesso pacchetto, è possibile eseguire la comunicazione tra processi tra di essi.

• Assicurarsi che tutte le estensioni installate dall'applicazione installeranno la posizione in cui è installata l'applicazione. Windows consente agli utenti e ai responsabili IT di modificare il percorso di installazione predefinito per i pacchetti. Vedere "Impostazioni->Sistema->Archiviazione->Altre impostazioni di archiviazione-> Modifica in cui salvare i nuovi contenuti -> Le nuove app verranno salvate in". Se si installa un'estensione con l'applicazione, assicurarsi che l'estensione non abbia restrizioni aggiuntive per le cartelle di installazione. Ad esempio, alcune estensioni possono disabilitare l'installazione dell'estensione in unità non di sistema. Si verificherà un errore 0x80073D01 (ERROR_DEPLOYMENT_BLOCKED_BY_POLICY) se la posizione predefinita è stata modificata.

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

• L'applicazione modifica l'hive del Registro di sistema HKEY_LOCAL_MACHINE (HKLM). Qualsiasi tentativo da parte dell'applicazione di creare una chiave HKLM o di aprirla per la modifica genererà un errore di accesso negato. Ricorda che la tua applicazione ha una visualizzazione virtualizzata privata del Registro di sistema, quindi la nozione di hive del Registro relativa all'utente e al computer (cioè HKEY_LOCAL_MACHINE, HKLM) non si applica. Sarà necessario trovare un altro modo per ottenere ciò per cui si stava usando HKLM, come scrivere invece in HKEY_CURRENT_USER (HKCU).

• L'applicazione usa una sottochiave del Registro di sistema ddeexec come mezzo per avviare un'altra app. Usare invece uno dei gestori verbi DelegateExecute come configurato dalle varie estensioni Activatable* nel manifesto del pacchetto dell'app.

• L'applicazione scrive nella cartella AppData o nel Registro di sistema con l'intenzione di condividere i dati con un'altra app. Dopo la conversione, AppData viene reindirizzato all'archivio dati dell'app locale, ovvero 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 tutte le voci che l'applicazione scrive nell'hive del Registro di sistema HKEY_CURRENT_USER vengono inserite in un percorso privato per utente, per ogni app. Per altri dettagli sul reindirizzamento dei file e del Registro di sistema, vedere Dietro le quinte di Desktop Bridge.

  Usare un mezzo diverso per la condivisione dei dati tra processi. Per ulteriori informazioni, vedi Memorizzare e recuperare le impostazioni e altri dati dell'applicazione.

• L'applicazione scrive nella directory di installazione dell'applicazione. Ad esempio, l'applicazione scrive in un file di log inserito nella stessa directory dell'exe. Questo non è supportato, quindi è necessario trovare un'altra posizione, ad esempio l'archivio dati dell'app locale.

• La tua applicazione utilizza la directory di lavoro attuale. In fase di esecuzione, l'applicazione desktop pacchettizzata non avrà la stessa directory di lavoro che avevi precedentemente specificato nel collegamento .LNK del desktop. È necessario modificare CWD in fase di esecuzione se la directory corretta è importante per il corretto funzionamento dell'applicazione.

  Annotazioni

  Se l'app deve scrivere nella directory di installazione o utilizzare la directory di lavoro corrente, puoi anche considerare di aggiungere una correzione di runtime usando Package Support Framework al pacchetto. Per altre informazioni, vedi questo articolo.

• L'installazione dell'applicazione richiede l'interazione dell'utente. Il programma di installazione dell'applicazione deve essere in grado di essere eseguito automaticamente e deve installare tutti i prerequisiti non presenti per impostazione predefinita in un'immagine pulita del sistema operativo.

• L'applicazione espone oggetti COM. I processi e le estensioni all'interno del pacchetto possono registrare e utilizzare server COM e OLE, sia in-process che out-of-process (OOP). Creators Update aggiunge il supporto COM in pacchetto che consente di registrare server COM e OLE OOP che sono ora visibili all'esterno del pacchetto. Consultare supporto per server COM e documenti 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 sulla lettura diretta del Registro di sistema, perché il percorso per COM in pacchetto si trova in una posizione privata.

• L'applicazione espone assembly GAC per l'uso da parte di altri processi. L'applicazione non può esporre assembly GAC per l'uso da parte di processi provenienti da eseguibili esterni al pacchetto dell'app di Windows. I processi dall'interno del pacchetto possono registrare e usare gli assembly GAC come di consueto, ma non saranno visibili esternamente. Ciò significa che gli scenari di interoperabilità come OLE non funzioneranno se richiamati da processi esterni.

• L'applicazione collega le librerie di runtime C (CRT) in modo non supportato. La libreria di runtime Microsoft C/C++ 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 l'applicazione usa la libreria di runtime C/C++, è necessario assicurarsi che sia collegata in modo supportato.

  Visual Studio 2017 supporta il collegamento statico e dinamico per consentire al codice di usare file DLL comuni o collegamenti statici per collegare la libreria direttamente al codice alla versione corrente di CRT. Se possibile, consigliamo di usare il collegamento dinamico con VS 2017.

  Il supporto nelle versioni precedenti di Visual Studio varia. Per informazioni dettagliate, vedere la tabella seguente:

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

  Nota: in tutti i casi, è necessario collegarsi alla versione CRT disponibile pubblicamente più recente.

• L'applicazione installa e carica assembly dalla cartella side-by-side 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. Questo non è supportato. Sarà necessario collegarli in modo statico collegandoli ai file di libreria ridistribuibili direttamente nel codice.

• L'applicazione usa una dipendenza nella cartella System32/SysWOW64. Per ottenere il funzionamento di queste DLL, devi includerle nella parte del file system virtuale del pacchetto dell'app di Windows. In questo modo l'applicazione si comporta come se le DLL fossero installate nella cartella System32/SysWOW64 . Nella radice del pacchetto creare una cartella denominata VFS. All'interno di tale cartella viene creata una cartella SystemX64 e SystemX86 . Posizionare quindi la versione a 32 bit della DLL nella cartella SystemX86 e posizionare la versione a 64 bit nella cartella SystemX64 .

• L'app 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 la versione 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 di 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, è necessario fare riferimento al pacchetto come dipendenza nel manifesto del pacchetto. Quando i clienti installano la versione definitiva dell'app da Microsoft Store, il pacchetto verrà installato dallo Store insieme alla tua app. Le dipendenze non verranno installate se si esegue il sideload dell'app. Per installare manualmente le dipendenze, è necessario installare il pacchetto framework appropriato usando il pacchetto di .appx appropriato per x86, x64 o ARM che si trova nelle cartelle di installazione elencate in precedenza.

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

  1. Passare alla cartella di installazione del pacchetto framework elencata in precedenza per la versione del runtime di Visual C++ usata dall'app.

  2. Aprire il file SDKManifest.xml in tale cartella, individuare l'attributo FrameworkIdentity-Debug o FrameworkIdentity-Retail (a seconda che si usi la versione di debug o definitiva del runtime) e copiare i Name valori e MinVersion da tale attributo. Ad esempio, ecco 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 dell'app, aggiungere l'elemento seguente <PackageDependency> sotto il nodo <Dependencies>. Assicurarsi di sostituire i Name valori e MinVersion con i valori copiati nel passaggio precedente. Nell'esempio seguente viene specificata 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. Esistono diversi problemi e avvertenze da tenere presenti quando si utilizzano le jump list.

  • L'architettura dell'app non corrisponde al sistema operativo. I jump list attualmente non funzionano correttamente se le architetture dell'applicazione e del sistema operativo non corrispondono (ad esempio, un'applicazione x86 in esecuzione in Windows x64). Al momento, non esiste una soluzione alternativa diversa da ricompilare l'applicazione all'architettura corrispondente.

  • L'applicazione crea voci jump list e chiama ICustomDestinationList::SetAppID o SetCurrentProcessExplicitAppUserModelID. Non impostare l'ID app a livello di codice. Così facendo, le voci dell'elenco rapido non verranno visualizzate. Se l'applicazione richiede un ID personalizzato, specificarlo usando il file manifesto. Per istruzioni, vedere Creare manualmente il pacchetto di un'applicazione desktop . L'ID app per l'applicazione viene specificato nella sezione YOUR_PRAID_HERE .

  • L'applicazione aggiunge un collegamento jump list shell che fa riferimento a un eseguibile nel pacchetto. Non è possibile avviare direttamente i file eseguibili nel pacchetto da una jump list (fatta eccezione per il percorso assoluto del .exeproprio dell'applicazione). Registrare invece un alias di esecuzione per l'app (che consente all'applicazione desktop in pacchetto di avviarsi tramite una parola chiave come se fosse nel PATH di sistema) e impostare il percorso di destinazione del collegamento sull'alias. Per informazioni dettagliate su come usare l'estensione appExecutionAlias, vedi Integrare l'applicazione desktop con Windows 10. Si noti che se sono necessari elementi del collegamento nella jump list affinché corrispondano al .exeoriginale, sarà necessario configurare elementi come l'icona usando SetIconLocation e il nome visualizzato tramite PKEY_Title, come si farebbe per altre voci personalizzate.

  • L'applicazione aggiunge voci di jump list che fanno riferimento agli asset nel pacchetto dell'app in base ai percorsi assoluti. Il percorso di installazione di un'applicazione può cambiare quando i pacchetti vengono aggiornati, modificando la posizione degli asset (ad esempio icone, documenti, eseguibili e così via). Se le voci della jump list fanno riferimento a tali asset in base a percorsi assoluti, l'applicazione deve aggiornare periodicamente la jump list (ad esempio all'avvio dell'applicazione) per garantire che i percorsi vengano risolti correttamente. In alternativa, usa le API UWP Windows.UI.StartScreen.JumpList , che ti consentono di fare riferimento a asset stringa e immagine usando lo schema URI ms-resource relativo al pacchetto(che è anche lingua, DPI e riconoscimento del contrasto elevato).

• L'applicazione avvia un'utilità per eseguire attività. Evitare di avviare utilità dei comandi, ad esempio PowerShell e Cmd.exe. Infatti, se gli utenti installano l'applicazione in un sistema che esegue Windows 10 S, l'applicazione non sarà in grado di avviarle affatto. Questo potrebbe impedire all'applicazione di inviare l'applicazione a Microsoft Store perché tutte le app inviate a Microsoft Store devono essere compatibili con Windows 10 S.

  L'avvio di un'utilità può spesso fornire un modo pratico per ottenere informazioni dal sistema operativo, accedere al Registro di sistema o accedere alle funzionalità del sistema. Tuttavia, puoi usare le API UWP per eseguire questi tipi di attività. Queste API sono più efficienti perché non richiedono l'esecuzione di un eseguibile separato, ma soprattutto impediscono all'applicazione di raggiungere l'esterno del pacchetto. La progettazione dell'app rimane coerente con l'isolamento, l'attendibilità e la sicurezza fornita con un'applicazione in pacchetto e l'applicazione si comporta come previsto nei sistemi che eseguono Windows 10 S.

• L'applicazione ospita componenti aggiuntivi, plug-in o estensioni. In molti casi, le estensioni di tipo COM continueranno probabilmente a funzionare finché l'estensione non è stata inserita nel pacchetto e viene installata come attendibilità totale. Questo perché questi programmi di installazione possono usare le funzionalità di attendibilità completa per modificare il Registro di sistema e posizionare i file di estensione ovunque l'applicazione host si aspetta di trovarli.

  Tuttavia, se tali estensioni sono in pacchetto e quindi installate come pacchetto di app di Windows, non funzioneranno perché ogni pacchetto (l'applicazione host e l'estensione) sarà isolato l'uno dall'altro. Per altre informazioni sul modo in cui le applicazioni sono isolate dal sistema, vedere Dietro le quinte di Desktop Bridge.

  Tutte le applicazioni e le estensioni installate dagli utenti in un sistema che esegue Windows 10 S devono essere installate come pacchetti di app di Windows. Pertanto, se si intende creare un pacchetto delle estensioni o si prevede di incoraggiare i collaboratori a crearli in un pacchetto, valutare come facilitare la comunicazione tra il pacchetto dell'applicazione host e qualsiasi pacchetto di estensione. Un modo per eseguire questa operazione consiste nell'usare un servizio app.

• L'applicazione genera codice. L'applicazione può generare codice usato in memoria, ma evitare di scrivere codice generato su disco perché il processo di certificazione dell'app Windows non può convalidare il codice prima dell'invio dell'app. Inoltre, le app che scrivono codice su disco non vengono eseguite correttamente nei sistemi che eseguono Windows 10 S. Questo potrebbe impedire all'applicazione di inviare l'applicazione a Microsoft Store perché tutte le app inviate a Microsoft Store devono essere compatibili con Windows 10 S.

Importante

Dopo aver creato il pacchetto dell'app di Windows, testare l'applicazione per assicurarsi che funzioni correttamente nei 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.