Condividi tramite

App di Windows: creazione di pacchetti, distribuzione ed elaborazione

  • Articolo

Nota

Alcune informazioni sono relative a un prodotto non definitivo, che potrebbe subire modifiche sostanziali prima del rilascio sul mercato. Microsoft non riconosce alcuna garanzia, espressa o implicita, in merito alle informazioni qui fornite.

In questo argomento vengono illustrate le opzioni relative a:

  • Se l'app verrà inserita o meno in un pacchetto.
  • Come implementare/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 fare le considerazioni precedenti, decidere innanzitutto 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.

In pacchetto o non in pacchetto

La decisione di rendere l'app in pacchetto o non in pacchetto è determinata prima 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 si deve 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'app in pacchetto viene inserita in un pacchetto usando la tecnologia MSIX. Vedere Che cos'è MSIX?.
    • Per una nuova app, il processo di creazione dei pacchetti è dritto (e alla fine di questa sezione sono disponibili informazioni su come eseguire questa operazione).
    • Per alcune app esistenti, puoi seguire lo stesso processo di creazione pacchetti di una nuova app. 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 è comunque una buona idea. Offre agli utenti il modo più semplice per installare, disinstallare e aggiornare l'app. Per altre info, vedere Implementazione/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 app in pacchetto e non in pacchetto, veder Panoramica della distribuzione, in particolare la sezione Vantaggi e svantaggi della creazione del pacchetto dell'app in questo argomento. In questo argomento viene inoltre menzionata l'opzione inserita in un pacchetto con percorso esterno.

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

Vedere anche la sezione Windows Package Manager e il client WinGet in questo articolo.

Implementazione/distribuzione/installazione

  • Un'app in pacchetto viene inserita in un pacchetto usando la tecnologia MSIX.
  • 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, viene ripristinato lo stato del sistema precedente all'installazione, senza artefatti rimanenti.
  • 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, vedere Che cos'è MSIX App Attach?.
  • Un pacchetto firmato trae vantaggio da una forte antimanomissione. Questo vantaggio è ancora maggiore di per un'app non in pacchetto installata in Programmi.

Vedere anche la sezione Windows Package Manager e il client WinGet in questo articolo.

AppContainer o Medium IL

L'opzione per eseguire l'app in un AppContainer o meno è una questione di sicurezza. Il processo di un'app AppContainer e i relativi processi figlio vengono eseguiti all'interno di un contenitore di app leggero in cui possono accedere solo alle risorse concesse in modo specifico. E sono isolati usando il file system e la virtualizzazione del Registro di sistema. Di conseguenza, le app implementate in un AppContainer non possono essere compromesse per consentire azioni dannose al di fuori delle limitate risorse assegnate.

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 Medium IL.

Per altre info, vedi AppContainer per le app legacy e app MSIX AppContainer.

Per informazioni su come configurare l'app per l'esecuzione in un'appContainer o in un ambiente con bilanciamento del carico intermedio Medium IL:

  • App WinUI 3 (Windows App SDK). Vedere l'attributo manifesto del pacchetto dell'app uap10:TrustLevel in Configurare un progetto WinUI 3 per AppContainer.
  • App desktop. Vedere la proprietà del progetto TrustLevel Visual Studio in app MSIX AppContainer (nella sezione appropriata per il tipo di app).
  • app 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, si dichiara la decisione AppContainer-o-Medium-IL nel file di progetto anziché in un manifesto del pacchetto dell'app.

Isolamento dell'app Win32

Importante

La funzionalità descritta in questa sezione è disponibile nelle versioni non definitive di Windows Insider Preview.

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 su 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, vedere Benvenuto nel repository di isolamento dell'app Win32.

Funzionalità dell'app

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

Esistono tuttavia alcuni scenari in cui anche un'app con il livello di bilanciamento del carico intermedio (ovvero, non un'app AppContainer) deve dichiarare una funzionalità. Un esempio è la funzionalità con restrizioni runFullTrust.

Per altre informazioni sulle funzionalità delle app, sui tipi di app a cui si applicano e su come configurarli, vedere Dichiarazioni di funzionalità dell'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 3) è 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, si può scegliere di configurare l'app desktop come AppContainer o un'app Medium IL.

Incluso nel pacchetto Unpackaged
AppContainer App desktop
App UWP		 App desktop
Medium IL App desktop App desktop

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

  • Le app desktop sono Windows .exe, in genere con una funzione punto di ingresso principale o winMain. Per configurare l'app come app desktop, impostare uap10:RuntimeBehavior su "packagedClassicApp" o "win32App".
    • Il valore "packagedClassicApp" indica un'app WinUI 3 (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 (inclusa un'app in pacchetto con posizione esterna).
  • Infine, l'impostazione uap10:RuntimeBehavior su "windowsApp" offre un'app UWP.

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

Windows App SDK: dipendente dal framework o indipendente

Se si sviluppa o si gestisce un'app che usa Windows App SDK, si ha un'ulteriore decisione da prendere. Poiché due modi in cui è possibile distribuire Windows App SDK da cui dipende l'app, e sono i seguenti:

  • Dipendente dal framework (impostazione predefinita). Per l'app è necessario che il runtime e/o il pacchetto Framework di Windows App SDK siano presenti nel computer di destinazione.
  • Indipendente. L'app include le relative dipendenze di Windows App SDK.

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

Windows Package Manager e il 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 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, la gestione pacchetti segue le istruzioni dichiarative per automatizzare il flusso di lavoro di installazione e la configurazione.

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

Per altre informazioni, vedere Gestione pacchetti Windows..