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.
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 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 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 computer) 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 della tua app vengono caricati in-process in processi che non sono inclusi nel tuo 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.
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 saved to -> New Apps will save to". Se si installa un'estensione con l'applicazione, assicurarsi che l'estensione non abbia restrizioni aggiuntive per le cartelle 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 è possibile 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. Tenere presente che l'applicazione ha una propria visualizzazione virtualizzata privata del Registro di sistema, quindi la nozione di hive del Registro di sistema a livello di utente e di computer (che è quello che HKLM è) non si applica. Sarà necessario trovare un altro modo per ottenere ciò che si stava usando HKLM per, come scrivere in HKEY_CURRENT_Uedizione Standard R (HKCU) invece.
L'applicazione usa una sottochiave del Registro di sistema ddeexec 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 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.
Usare un mezzo diverso per la condivisione dei dati tra processi. Per altre info, vedi Archiviare e recuperare le 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. Questo non è supportato, quindi è necessario trovare un'altra posizione, ad esempio l'archivio dati dell'app locale.
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 all'interno del pacchetto possono registrare e usare i server COM e OLE, sia in-process sia out-of-process (OOP). Creators Update aggiunge il supporto COM in pacchetto che offre la possibilità di registrare i server OOP COM e OLE che sono 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. Ciò 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 Microsoft C/C++ fornisce routine per la programmazione per il sistema operativo Microsoft Windows. Queste routine consentono di automatizzare 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 varia. Per informazioni dettagliate, vedere la tabella seguente:
Versione di Visual Studio Collegamento dinamico Collegamento statico 2005 (VC 8) Non supportato Supportato 2008 (VC 9) Non supportato Supportato 2010 (VC 10) Supportata Supportata 2012 (VC 11) Supportata Non supportato 2013 (VC 12) Supportata Non supportato 2015 e 2017 (VC 14) Supportata Supportata Nota: in tutti i casi, è necessario collegarsi alla versione CRT disponibile pubblicamente più recente.
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. 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 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 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'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++:
Passa alla cartella di installazione del pacchetto framework sopra indicata per la versione del runtime di Visual C++ usata dall'app.
Apri il file SDKManifest.xml nella cartella, individua l'attributo
FrameworkIdentity-DebugoFrameworkIdentity-Retail(a seconda che usi la versione di debug o la versione finale del runtime) e copia i valoriNameeMinVersionda tale attributo. Ecco ad esempio l'attributoFrameworkIdentity-Retailper 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'"Nel manifesto del pacchetto per l'app aggiungi l'elemento
<PackageDependency>seguente nel nodo<Dependencies>. Assicurati di sostituire i valoriNameeMinVersioncon 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'app 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 l'ID app a livello di codice nel codice. In questo modo le voci della jump list non verranno 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'ID app per l'applicazione viene 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 avviare direttamente i file eseguibili nel pacchetto da una jump list ,ad eccezione del percorso assoluto di un file con estensione exe di un'app. 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. Si noti che se sono necessari asset del collegamento nella jump list in modo che corrispondano al file exe originale, sarà necessario impostare asset come l'icona usando SetIconLocation e il nome visualizzato con PKEY_Title come si farebbe 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, 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 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 installate dagli utenti 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. 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 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.