Informazioni sull'esecuzione in Windows di app desktop in pacchetto

  • Articolo

Questo argomento descrive i tipi di app desktop per cui è possibile creare un pacchetto di app di Windows, insieme ad alcuni comportamenti del sistema operativo (OS) e altre specifiche, che sono importanti da tenere presenti. Verranno fornite informazioni dettagliate sugli elementi seguenti (come si vedrà, il comportamento specifico dipende dal tipo di app):

Tipi di app desktop

Esistono due tipi di app desktop che è possibile creare e creare un pacchetto. Dichiari il tipo dell'app nel manifesto del pacchetto dell'app usando l'attributo uap10:RuntimeBehavior dell'elemento Application :

  • Un tipo include sia le app WinUI 3 (che usano la SDK per app di Windows) che le app Desktop Bridge (Centennial). Dichiarato con uap10:RuntimeBehavior="packagedClassicApp".
  • L'altro tipo rappresenta altri tipi di app Win32, incluse le app in pacchetto con posizione esterna. Dichiarato con uap10:RuntimeBehavior="win32App".

anche le app piattaforma UWP (Universal Windows Platform) (uap10:RuntimeBehavior="windowsApp"UWP) sono incluse nel pacchetto, ma questo argomento non è relativo.

E quindi l'attributo uap10:TrustLevel (dello stesso elemento Application ) determina se il processo dell'app in pacchetto viene eseguito all'interno di un contenitore di app.

  • Un'app di attendibilità completa. Dichiarato con uap10:TrustLevel="mediumIL".
  • AppContainer. Dichiarato con uap10:TrustLevel="appContainer". Viene eseguito in un contenitore di app leggero (ed è quindi isolato usando il file system e la virtualizzazione del Registro di sistema). Per altre info, vedi App MSIXAppContainer.

Importante

Per altri dettagli, dipendenze e requisiti di funzionalità, vedere la documentazione relativa a questi due attributi in Application. Vedi anche uap10 è stato introdotto in Windows 10 versione 2004 (10.0; Build 19041).

Scopo della creazione di pacchetti e dei contenitori di app

Lo scopo della creazione del pacchetto dell'app è concedere l'identità del pacchetto in fase di esecuzione. L'identità del pacchetto è necessaria per determinate funzionalità di Windows (vedere Funzionalità che richiedono l'identità del pacchetto). È possibile creare un pacchetto di tutte le combinazioni di tipi di app descritte in precedenza (e quindi trarre vantaggio dall'identità del pacchetto).

Ma l'obiettivo principale di un'app AppContainer è separare lo stato dell'app dallo stato del sistema il più possibile, mantenendo al contempo la compatibilità con altre app. Windows esegue questa operazione rilevando e reindirizzando determinate modifiche apportate al file system e al Registro di sistema in fase di esecuzione (nota come virtualizzazione). Verrà chiamato quando una sezione si applica solo alle app virtualizzate.

Installazione

I pacchetti dell'app vengono installati in base all'utente anziché a livello di sistema. Il percorso predefinito per i nuovi pacchetti in un nuovo computer è in C:\Program Files\WindowsApps\<package_full_name>, con l'eseguibile denominato app_name.exe. Ma i pacchetti possono essere installati in altre posizioni; Ad esempio, i comandi Start di Visual Studio usano .$(OutDir)

Dopo la distribuzione, i file del pacchetto sono contrassegnati come di sola lettura e sono fortemente bloccati dal sistema operativo. Windows impedisce l'avvio delle app se tali file vengono manomessi.

Il C:\Program Files\WindowsApps percorso è noto come PackageVolume. Tale posizione è l'oggetto PackageVolume predefinito fornito da Windows; ma è possibile creare un PackageVolume in qualsiasi unità e in qualsiasi percorso. Inoltre, non tutti i pacchetti vengono installati in packageVolume (vedere l'esempio di Visual Studio precedente).

File system

Il sistema operativo supporta diversi livelli di operazioni del file system per le app desktop in pacchetto, a seconda del percorso della cartella.

Ottimizzato per il dispositivo

Per evitare la duplicazione dei file (per ottimizzare lo spazio di archiviazione su disco e ridurre la larghezza di banda necessaria durante il download dei file), il sistema operativo sfrutta l'archiviazione singola e il collegamento rigido dei file. Quando un utente scarica un pacchetto MSIX, AppxManifest.xml viene usato per determinare se i dati contenuti nel pacchetto esistono già su disco da un'installazione precedente del pacchetto. Se lo stesso file esiste in più pacchetti MSIX, il sistema operativo archivia il file condiviso su disco una sola volta e crea collegamenti rigidi da entrambi i pacchetti al file condiviso. Poiché i file vengono scaricati in blocchi di 64 KB, anche se esiste una percentuale di un file scaricato su disco, viene scaricato solo l'incremento diverso. Ciò riduce la larghezza di banda usata per il download.

Operazioni relative ad AppData in Windows 10, versione 1903 e successive

Questa sezione si applica solo alle app virtualizzate.

Tutti i file e le cartelle appena creati nella cartella dell'utente (ad esempio , C:\Users\<user_name>\AppData) vengono scritti in un percorso privato per utente, per app, ma unito in fase di AppData esecuzione per essere visualizzato nella posizione realeAppData. Ciò consente un certo grado di separazione dello stato per gli artefatti usati solo dall'app stessa; che consente al sistema di pulire tali file quando l'app viene disinstallata.

Le modifiche apportate ai file esistenti nella cartella dell'utente AppData sono consentite per offrire un livello più elevato di compatibilità e interattività tra le app e il sistema operativo. Ciò riduce il sistema "rot" perché il sistema operativo è a conoscenza di ogni modifica di file o directory apportata da un'app. La separazione dello stato consente anche alle app desktop in pacchetto di selezionare la posizione in cui è stata interrotta una versione non in pacchetto della stessa app. Si noti che il sistema operativo non supporta una cartella VFS (Virtual File System) per la cartella dell'utente AppData .

Operazioni di AppData su sistemi operativi precedenti a Windows 10, versione 1903

Questa sezione si applica solo alle app virtualizzate.

Tutte le scritture nella cartella dell'utente AppData ( ad esempio C:\Users\<user_name>\AppData) , incluse le operazioni di creazione, eliminazione e aggiornamento, vengono copiate in scrittura in un percorso privato per utente, per app. Ciò crea l'illusione che l'app in pacchetto stia modificando il reale AppData quando sta effettivamente modificando una copia privata. Reindirizzando le scritture in questo modo, il sistema può tenere traccia di tutte le modifiche apportate ai file dall'app. Ciò consente al sistema di pulire tali file quando l'app viene disinstallata, riducendo così il sistema "rot" e offrendo un'esperienza migliore di rimozione delle app per l'utente.

Directory di lavoro e file dell'applicazione

Questa sezione si applica solo alle app virtualizzate.

Oltre a reindirizzare AppData, le cartelle note di Windows (System32, e Program Files (x86)così via) vengono unite dinamicamente con le directory corrispondenti nel pacchetto dell'app. Ogni pacchetto contiene una cartella denominata VFS nella radice. Tutte le letture di directory o file nella VFS directory vengono unite in fase di esecuzione con le rispettive controparti native. Ad esempio, un'app può contenere C:\Program Files\WindowsApps\<package_full_name>\VFS\SystemX86\vc10.dll come parte del pacchetto dell'app, ma il file sembra essere installato in C:\Windows\System32\vc10.dll. Ciò mantiene la compatibilità con le app desktop che prevedono che i file si trovano in posizioni non di pacchetto.

Le scritture in file/cartelle nel pacchetto dell'app non sono consentite. Le scritture in file e cartelle che non fanno parte del pacchetto vengono ignorate dal sistema operativo e sono consentite purché l'utente disponga dell'autorizzazione.

Operazioni comuni del file system

Questa breve tabella di riferimento mostra le operazioni comuni sul file system e il modo in cui vengono gestite dal sistema operativo.

Operazione Result Esempio
Leggere o enumerare un file o una cartella windows nota Unione dinamica di C:\Program Files\<package_full_name>\VFS\<well_known_folder> con la controparte di sistema locale. La lettura C:\Windows\System32 restituisce il contenuto di C:\Windows\System32 più il contenuto di C:\Program Files\WindowsApps\<package_full_name>\VFS\SystemX86.
Scrivi in AppData Windows 10, versione 1903 e successive: i nuovi file e cartelle creati nelle directory seguenti vengono reindirizzati a un percorso privato per utente e per pacchetto:
  • Locale
  • Local\Microsoft
  • Roaming
  • Roaming\Microsoft
  • Roaming\Microsoft\Windows\Start Menu\Programs
In risposta a un comando di apertura file, il sistema operativo aprirà prima il file dal percorso, per singolo utente e singolo pacchetto. Se tale posizione non esiste, il sistema operativo tenterà di aprire il file dal percorso reale AppData . Se il file viene aperto dal percorso reale AppData , non viene eseguita alcuna virtualizzazione per tale file. Le eliminazioni di file in AppData sono consentite se l'utente dispone delle autorizzazioni.

Versioni precedenti a Windows 10, versione 1903: copia in scrittura in un percorso per utente, per app.

 AppData è in C:\Users\<user_name>\AppDatagenere .
Scrivere all'interno del pacchetto Non consentiti. Il pacchetto è di sola lettura. Le scritture in C:\Program Files\WindowsApps\<package_full_name> non sono consentite.
Scrivere all'esterno del pacchetto Consentito se l'utente dispone delle autorizzazioni. È consentito scrivere in C:\Windows\System32\foo.dll se il pacchetto non contiene C:\Program Files\WindowsApps\<package_full_name>\VFS\SystemX86\foo.dlle l'utente dispone delle autorizzazioni.

Percorsi VFS in pacchetto

Questa sezione si applica solo alle app virtualizzate.

Questa tabella mostra dove i file spediti come parte del pacchetto sono sovrapposti nel sistema per l'app. L'app percepisce questi file in modo che si trovano nelle posizioni di sistema elencate quando in realtà si trovano nei percorsi reindirizzati all'interno C:\Program Files\WindowsApps\<package_full_name>\VFSdi . I percorsi FOLDERID provengono dalle costanti KNOWNFOLDERID.

Posizione del sistema Percorso reindirizzato (in [<package_root>]\VFS) Valido per le architetture
FOLDERID_SystemX86 SystemX86 x86, amd64
FOLDERID_System SystemX64 amd64
FOLDERID_ProgramFilesX86 ProgramFilesX86 x86, amd6
FOLDERID_ProgramFilesX64 ProgramFilesX64 amd64
FOLDERID_ProgramFilesCommonX86 ProgramFilesCommonX86 x86, amd64
FOLDERID_ProgramFilesCommonX64 ProgramFilesCommonX64 amd64
FOLDERID_Windows Windows x86, amd64
FOLDERID_ProgramData Comune AppData x86, amd64
FOLDERID_System\catroot AppVSystem32Catroot x86, amd64
FOLDERID_System\catroot2 AppVSystem32Catroot2 x86, amd64
FOLDERID_System\drivers\etc AppVSystem32DriversEtc x86, amd64
FOLDERID_System\driverstore AppVSystem32Driverstore x86, amd64
FOLDERID_System\logfiles AppVSystem32Logfiles x86, amd64
FOLDERID_System\spool AppVSystem32Spool x86, amd64

Registro

Questa sezione (e le relative sezioni secondarie) si applica solo alle app virtualizzate.

I pacchetti dell'app contengono un registry.dat file, che funge da equivalente logico (virtuale) di HKLM\Software nel registro reale. In fase di esecuzione, il Registro di sistema virtuale unisce il contenuto di tale hive nell'hive di sistema nativo per fornire una singola visualizzazione di entrambi. Ad esempio, se registry.dat contiene una singola chiave Foo, verrà visualizzata anche una lettura di HKLM\Software in fase di esecuzione che conterrà Foo (oltre a tutte le chiavi di sistema native).

Anche se i pacchetti MSIX includono chiavi HKLM e HKCU , vengono trattati in modo diverso. Solo le chiavi in HKLM\Software fanno parte del pacchetto. Le chiavi in HKCU o altre parti del Registro di sistema non sono. Le scritture in chiavi o valori nel pacchetto non sono consentite. Le scritture in chiavi o valori che non fanno parte del pacchetto sono consentite a condizione che l'utente disponga delle autorizzazioni.

Tutte le scritture in HKCU vengono copiate in scrittura in un percorso privato per utente, per app. Tradizionalmente, i disinstallatori non sono in grado di pulire HKEY_CURRENT_Uedizione Standard R perché i dati del Registro di sistema per gli utenti disconnessi sono smontati e non disponibili.

Tutte le scritture vengono mantenute durante l'aggiornamento del pacchetto ed eliminate solo quando l'app viene rimossa completamente.

Operazioni comuni del Registro di sistema

La maggior parte di questa sezione si applica solo alle app virtualizzate.

Questa breve tabella di riferimento mostra le operazioni comuni sul Registro di sistema e indica come vengono gestite dal sistema operativo.

Operazione Result Esempio
Leggere o enumerare HKLM\Software Unione dinamica dell'hive del pacchetto con la controparte del sistema locale. Se registry.dat contiene una singola chiave Foo, in fase di esecuzione una lettura di HKLM\Software mostra il contenuto di HKLM\Software e HKLM\Software\Foo.
Scritture in HKCU Copiato in scrittura in una posizione privata per utente e per app. Uguale AppData a per i file.
Scrive all'interno del pacchetto. Non consentiti. Il pacchetto è di sola lettura. Le scritture in HKLM\Software non sono consentite se esiste una chiave/valore corrispondente nell'hive del pacchetto.
Scrive all'esterno del pacchetto Ignorate dal sistema operativo. Consentito se l'utente dispone delle autorizzazioni. Le scritture in HKLM\Software sono consentite purché non esista una chiave/valore corrispondente nell'hive del pacchetto e che l'utente disponga delle autorizzazioni di accesso corrette.

Disinstallazione

Questa sezione si applica solo alle app virtualizzate.

Quando un pacchetto viene disinstallato dall'utente, tutti i file e le cartelle presenti C:\Program Files\WindowsApps\<package_full_name> in vengono rimossi, nonché eventuali scritture reindirizzate in AppData o nel Registro di sistema acquisito durante il processo di creazione del pacchetto.