App di Windows: creazione di pacchetti, distribuzione ed elaborazione

In questo argomento vengono illustrate le opzioni relative a:

• Indica se l'app verrà inserita in un pacchetto.
• Come distribuire/distribuire l'app e come verrà installata.
• Il processo di runtime dell'app, come sarà isolato; e quali API saranno disponibili.

È possibile prendere queste decisioni sia per le app nuove che per quelle esistenti. Tuttavia, se si è ancora nella fase di pianificazione per una nuova app, prima di iniziare a considerare le considerazioni precedenti, prima di decidere quale piattaforma di sviluppo e framework dell'interfaccia utente si userà per l'app. Per questa decisione, vedere Panoramica delle opzioni di sviluppo di Windows.

Confezionato o sfuso

La decisione di rendere l'app impacchettata o non impacchettata è determinata innanzitutto da un concetto noto come identità del pacchetto, che verrà descritto in questa sezione. Se non è necessario, la decisione dipende dall'esperienza di installazione desiderata per se stessi e per gli utenti. Esaminiamo i dettagli di queste cose.

Molte funzionalità di estendibilità di Windows, tra cui attività in background, notifiche, riquadri animati, estensioni del menu di scelta rapida personalizzate e destinazioni di condivisione, possono essere usate da un'app solo se l'app dispone dell'identità del pacchetto in fase di esecuzione. Questo perché il sistema operativo (OS) deve essere in grado di identificare il chiamante dell'API corrispondente. Vedere Funzionalità che richiedono l'identità del pacchetto.

• Se devi usare una di queste funzionalità, l'app necessita dell'identità del pacchetto. E quindi deve essere un'app in pacchetto (le app in pacchetto sono l'unico tipo con identità del pacchetto). Un'applicazione pacchettizzata viene raggruppata utilizzando la tecnologia MSIX. Consultare Che cos'è MSIX?.
  • Per una nuova app, la procedura di impacchettamento è semplice (e alla fine di questa sezione sono disponibili informazioni su come effettuarlo).
  • Per alcune app esistenti, puoi seguire la stessa procedura di packaging sia per una nuova app che per un'app esistente. Tuttavia, poiché alcune app esistenti non sono ancora pronte per tutti i contenuti da presentare all'interno di un pacchetto MSIX, è possibile creare un pacchetto dell'app con posizione esterna. Ciò consente all'app di avere l'identità del pacchetto, riuscendo in questo modo a usare le funzionalità che la richiedono. Per altre informazioni, vedere Concedere l'identità del pacchetto tramite creazione di pacchetti con posizione esterna.
• Anche se non è necessario usare una di queste funzionalità, la creazione di un'app in pacchetto è ancora una buona idea. Offre agli utenti il modo più semplice per installare, disinstallare e aggiornare l'app. Per altre info, vedere Distribuzione/distribuzione/installazione in questo argomento.
• Ma la creazione di un'app non in pacchetto è un'opzione.

Il takeaway è che le app in pacchetto sono l'unico tipo che hanno l'identità del pacchetto (e hanno la migliore esperienza di installazione). Un'app non in pacchetto non ha un'identità del pacchetto; quindi non può usare le API/funzionalità indicate in precedenza.

Per altri dettagli su pacchettizzato e non pacchettizzato, vedere Panoramica della distribuzione; in particolare, la sezione Vantaggi e svantaggi dell'impacchettamento dell'app in questo argomento. In questo argomento viene inoltre menzionata l'opzione packaged with external location.

Per informazioni su come configurare l'app come in pacchetto o senza pacchetti:

• App WinUI (Windows App SDK). Consultare la proprietà del AppxPackage progetto di Visual Studio nelle proprietà del progetto e fare riferimento a Creare il primo progetto WinUI utilizzando il Windows App SDK.
• App desktop. Vedi Configurare l'app desktop per la creazione di pacchetti MSIX.
• App della piattaforma UWP (Universal Windows Platform). Le app UWP sono già configurate come in pacchetto; e tale configurazione non può essere modificata.

Vedere anche la sezione Gestione pacchetti di Windows e il client WinGet in questo argomento.

Implementazione/distribuzione/installazione

• Un'applicazione confezionata viene impacchettata usando la tecnologia MSIX.
  • Un'app in pacchetto può essere installata anche tramite MSIX. Tuttavia, se si sceglie di creare un pacchetto con posizione esterna, è possibile considerarlo come un modello BYOI (Bring-Your-Own-Installer). Con questa opzione sarà quindi necessario un po' di lavoro per il programma di installazione. Per altre informazioni, vedere Concedere l'identità del pacchetto tramite creazione di pacchetti con posizione esterna.
• Un'app non in pacchetto non implica affatto MSIX.

Quindi, perché è importante se l'app è in pacchetto o meno?

• MSIX offre agli utenti un modo semplice per installare, disinstallare e aggiornare l'app. La disinstallazione è pulita: quando l'app viene disinstallata, il sistema viene ripristinato allo stesso stato in cui si trovava prima dell'installazione; nessun artefatto viene lasciato indietro.
• Questo tipo di app supporta anche aggiornamenti incrementali e automatici.
• Microsoft Store ottimizza le app di questo tipo (anche se possono essere usate in o fuori dallo Store).
• Si tratta di un percorso semplice da usare tramite MSIX App Attach (per le macchine virtuali di Desktop virtuale Azure). Per altre info, vedi Che cos'è MSIX App Attach?.
• Un pacchetto firmato beneficia di una forte protezione contro la manomissione. Questo vantaggio è ancora maggiore di quello di un'app non in pacchetto installata in Programmi.

Vedere anche la sezione Gestione pacchetti di Windows e il client WinGet in questo argomento.

AppContainer o Medium IL

L'opzione per eseguire l'app in un AppContainer o meno è una questione di sicurezza. Il processo di un'applicazione AppContainer e i relativi processi figlio vengono eseguiti all'interno di un contenitore di app leggero, dove possono accedere solo alle risorse che sono state specificamente concesse a loro. Sono isolati usando la virtualizzazione del file system e del registro. Di conseguenza, le app implementate in un AppContainer non possono essere compromesse per consentire azioni dannose al di fuori delle risorse assegnate limitate.

Le app in pacchetto o non in pacchetto possono essere configurate per l'esecuzione in un AppContainer. Ma il processo è più semplice per le app in pacchetto. Se un'app non è un'app AppContainer, si tratta di un'app IL Medio.

Per ulteriori informazioni, vedi AppContainer per app legacy e AppContainer MSIX app.

Per informazioni su come configurare l'app per l'esecuzione in un AppContainer o a un livello di integrità intermedio:

• App WinUI (Windows App SDK). Vedi l'attributo manifesto del uap10:TrustLevel pacchetto dell'app in Configurazione di un progetto WinUI per AppContainer.
• App desktop. Consultare la proprietà del progetto TrustLevel di Visual Studio nelle app MSIX AppContainer (nella sezione adatta al tipo di app).
• App della piattaforma UWP (Universal Windows Platform). Le app UWP sono già configurate per l'esecuzione in un AppContainer; e tale configurazione non può essere modificata.

Tenere presente che le app non in pacchetto non hanno un manifesto del pacchetto dell'app. Quindi, per le app non in pacchetto, dichiari la decisione AppContainer-or-Medium-IL nel file di progetto anziché in un manifesto del pacchetto dell'app.

Isolamento dell'app Win32

L'isolamento delle app Win32 è una funzionalità di sicurezza imminente in Windows che, in caso di compromissione di un'app, consente di contenere i danni e proteggere le scelte di privacy degli utenti. Questa funzionalità si basa sulla base di AppContainers e componenti che virtualizzano le risorse e forniscono l'accesso negoziato ad altre risorse. Per la documentazione e gli strumenti che consentono di isolare le app, vedi Benvenuto nel repository di isolamento delle app Win32.

Funzionalità dell'app

Le funzionalità dell'app (ad esempio, internetClient, posizione, microfono e Bluetooth) sono rilevanti principalmente per le app in pacchetto eseguite in un AppContainer. In questo modo sono incluse tutte le app UWP (Universal Windows Platform) e alcune app desktop.

Tuttavia, esistono alcuni scenari in cui anche un'app con integrità media (ovvero non un'app AppContainer) deve dichiarare una capacità. Un esempio è la capacità ristretta runFullTrust.

Per altre informazioni sulle funzionalità delle app, sui tipi di app a cui si applicano e su come configurarli, vedi Dichiarazioni di funzionalità delle app. Configurare le funzionalità nel manifesto del pacchetto dell'app; ed è per questo che si applicano solo alle app in pacchetto.

Tipi di app

Le app desktop e le app UWP (Universal Windows Platform) sono i due tipi principali di app, anche se esistono diversi tipi di app nella famiglia di app desktop . La scelta di un framework dell'interfaccia utente( WinForms, WPF, Win32, Direct 2D/3D, UWP o WinUI) è un'opzione indipendente in qualche modo dalle configurazioni descritte in questo argomento.

Si esaminerà tuttavia il modo in cui questi tipi di app possono differire l'uno dall'altro in termini di creazione di pacchetti, distribuzione e processo.

Prima di tutto, tutte le app UWP vengono incluse in un pacchetto e vengono eseguite in un AppContainer. Ma per le app desktop, le cose sono più flessibili. È possibile scegliere di creare o meno il pacchetto dell'app desktop. Inoltre, indipendentemente da tale decisione, puoi scegliere di configurare l'app desktop come AppContainer o come app con livello di integrità media.

Per le app in pacchetto, per configurare il tipo di app desiderata, usi l'attributo uap10:RuntimeBehavior nel manifesto del pacchetto dell'app (vedi Applicazione (Windows 10)).

• Le app desktop sono Windows .exe, in genere con una funzione punto di ingresso principale o WinMain . Per configurare la tua app come app desktop, imposta uap10:RuntimeBehavior su "packagedClassicApp" o "win32App".
  • Il valore "packagedClassicApp" indica un'app WinUI (Windows App SDK) o un'app Desktop Bridge (Centennial). La differenza è che un'app Centennial viene eseguita in un AppContainer.
  • E "win32App" indica qualsiasi altro tipo di app Win32 (incluso un'app in pacchetto con posizione esterna).
• Infine, l'impostazione uap10:RuntimeBehavior su "windowsApp" ti offre un'app UWP.

Per tutte le opzioni per i tipi di app che è possibile sviluppare, vedi Sviluppo di app di Windows: opzioni e funzionalità.

Windows App SDK: dipendente dal framework o indipendente

Se stai sviluppando o mantenendo un'app che usa Windows App SDK, hai un'ulteriore decisione da prendere. Poiché esistono i due modi seguenti in cui è possibile distribuire Windows App SDK da cui dipende l'app:

• Dipendente dal framework (impostazione predefinita). L'app richiede che il runtime e/o il pacchetto Framework del Windows App SDK siano presenti sul computer di destinazione.
• Autonomo. L'app porta con sé le dipendenze di Windows App SDK.

Per altre info, vedi Panoramica della distribuzione di Windows App SDK.

Gestione pacchetti Windows e client WinGet

Uno strumento di gestione pacchetti consente agli utenti di installare, aggiornare o configurare il software automatizzando il flusso di lavoro. Gli strumenti di gestione pacchetti possono aiutare a installare qualsiasi software, ma tendono a essere usati principalmente per installare gli strumenti di sviluppo. Quindi, se stai creando uno strumento di sviluppo, potresti essere particolarmente interessato a questa opzione. Ma ecco come funziona:

• L'utente, in qualità di sviluppatore di software, definisce lo strumento di gestione pacchetti (sotto forma di istruzioni dichiarative) tutte le parti necessarie per un'installazione corretta del prodotto.
• Quando un utente installa il software, gestione pacchetti segue le istruzioni dichiarative per automatizzare il flusso di lavoro di installazione e configurazione.

Il risultato è una riduzione del tempo impiegato per preparare l'ambiente di un utente e una migliore compatibilità tra i componenti installati. E puoi usare Gestione pacchetti di Windows per distribuire le app in pacchetto o non in pacchetto in formati come .msix, .msie .exe.

Per altre info, vedi Gestione pacchetti di Windows.