Panoramica del packaging

La creazione di pacchetti definisce la modalità di installazione, aggiornamento e integrazione dell'app con Windows. Le app WinUI 3 vengono incluse in un pacchetto per impostazione predefinita, mentre molte app desktop, ad esempio le applicazioni Win32 tradizionali, vengono eseguite senza pacchetto. La scelta tra un'app in pacchetto o non in pacchetto influisce sulle funzionalità che è possibile usare, sul modello di distribuzione su cui si basa e sull'esperienza complessiva che i clienti ottengono.

Annotazioni

Creazione di una nuova app WinUI 3? Per impostazione predefinita, l'utente è già incluso nel pacchetto. Le indicazioni seguenti sono più rilevanti per gli sviluppatori che devono effettuare una scelta esplicita, in genere quando si effettua la conversione di un'app esistente, la distribuzione in computer aziendali o l'aggiunta di Windows funzionalità a un'app che non è stata originariamente inserita in un pacchetto.

Perché la creazione di pacchetti di app è importante

Le app in pacchetto traggono vantaggio da un modello di installazione pulita, aggiornamenti automatici e accesso alle funzionalità di Windows che richiedono l'identità del pacchetto, incluse attività in background, notifiche, estensioni del menu di scelta rapida, destinazioni di condivisione e altri punti di estendibilità. La creazione di pacchetti consente anche di garantire distribuzioni più pulite, aggiornamenti affidabili e distribuzione semplificata tramite canali come gli strumenti di distribuzione di Microsoft Store e aziendali.

Funzionalità che richiedono l'identità del pacchetto

Queste funzionalità di Windows funzionano solo nelle app con identità del pacchetto, tramite pacchetti MSIX completi o confezionamento con posizione esterna (creazione di pacchetti sparsi).

Feature Descrizione
Attività in background Eseguire il codice quando l'app non è in primo piano, ad esempio per sincronizzare i dati, elaborare i download o rispondere agli eventi di sistema.
Windows API di intelligenza artificiale (Phi Silica, OCR e così via) Accedere alle funzionalità di intelligenza artificiale sul dispositivo, ad esempio modelli linguistici locali, riconoscimento del testo e analisi delle immagini.
Notifiche push (WNS) Ricevere notifiche in tempo reale dal servizio cloud tramite il servizio di notifica Windows.
Condividi destinazione Consenti agli utenti di condividere il contenuto da altre app direttamente nei tuoi tramite il foglio di condivisione di sistema.
Estensioni del menu di scelta rapida personalizzate Aggiungi le azioni dell'app al menu di scelta rapida in Esplora file e in altre interfacce della shell.
Associazioni di tipo e protocollo di file Registrare l'app come gestore per tipi di file o protocolli URI specifici ,ad esempio yourapp://.
Attività di avvio Avviare automaticamente l'app quando l'utente accede a Windows.
Servizi app Esporre i servizi in background che altre app possono chiamare, abilitando la comunicazione tra app.

Suggerimento

Se non si esegue il pacchetto e si verificano errori E_ILLEGAL_METHOD_CALL o APPMODEL_ERROR_NO_PACKAGE quando si chiamano api Windows, questo è il requisito di identità del pacchetto. Vedi imballaggio con ubicazione esterna (imballaggio sparso) come la soluzione a minor attrito.

Per altre informazioni, vedere Funzionalità che richiedono l'identità del pacchetto.

Modelli di packaging in sintesi

Modello Identità del pacchetto Installatore Store idoneo Ideale per
Pacchettizzato (MSIX) ✅ Sì MSIX sostituisce il programma di installazione ✅ Sì (invio MSIX) Nuove app, pubblicazione nello Store, MDM aziendale
Creazione di pacchetti con posizione esterna ✅ Sì Programma di installazione esistente ✅ Sì (invio MSI/EXE) App esistenti con programma di installazione proprio, ISV
Non confezionato ❌ No Programma di installazione MSI o EXE (anche: XCopy o script per la distribuzione non nello Store) ✅ Sì (invio MSI/EXE : richiede un programma di installazione MSI o EXE con supporto per l'installazione invisibile all'utente) Distribuzione Win32 generale, strumenti interni

Applicazioni confezionate (MSIX)

Le app in pacchetto usano MSIX e hanno identità package, necessaria per molti punti di estendibilità Windows. L'identità del pacchetto consente Windows di identificare in modo affidabile il chiamante delle API della piattaforma, motivo per cui queste funzionalità dipendono da essa.

  • Le app in pacchetto vengono in genere eseguite in un contenitore di app leggero con file system e virtualizzazione del Registro di sistema (vedere AppContainer per le app legacy e le app MSIX AppContainer).
  • Le app possono anche essere configurate per non essere eseguite in un contenitore di app, se necessario.
  • MSIX viene usato sia per la creazione di pacchetti che per l'installazione (vedere Che cos'è MSIX?).

Creazione di pacchetti con posizione esterna (pacchetti sparsi)

La creazione di pacchetti con una posizione esterna (denominata anche pacchetti sparse) consente di registrare un piccolo pacchetto di identità insieme all'app esistente, senza modificare il programma di installazione, i percorsi binari o il processo di aggiornamento. È stato introdotto in Windows 10 versione 2004 (build 19041).

Questo è il punto ideale per le app Win32/macchine virtuali Windows/WinForms esistenti che vengono fornite tramite il proprio programma di installazione (NSIS, WiX, InstallShield e così via) e non vogliono sostituirlo con MSIX. Si registra un pacchetto di identità leggero, i file binari rimangono dove si trovano e si sblocca il set completo di funzionalità di Windows di package-identity-gated.

Capability MSIX Posizione esterna
Sostituisce il programma di installazione Sì No
File binari all'interno del pacchetto Sì Nessuno (esterno)
Store idoneo Sì (invio MSIX) Sì (invio MSI/EXE)
Identità del pacchetto Sì Sì
Meccanismo di aggiornamento Aggiornamento MSIX Il meccanismo esistente

→ procedura dettagliata completa: Concedere l'identità del pacchetto tramite creazione di pacchetti con posizione esterna

App non confezionate

Le app non in pacchetto non usano MSIX e non hanno un'identità del pacchetto, il che significa che non possono accedere alle funzionalità elencate in precedenza.

  • Rimangono completamente privi di restrizioni in termini di superficie API, accesso al file system, accesso al Registro di sistema, elevazione e modello di processo.
  • L'installazione e gli aggiornamenti si basano su .exe, .msi, programmi di installazione personalizzati, ClickOnce o xcopy.

Prima di impegnarti in uno stato non confezionato, controlla la tabella delle funzionalità precedente rispetto alla tua roadmap. Se le notifiche, le attività in background o le API di intelligenza artificiale sono imminenti, prendere in considerazione di iniziare con un approccio confezionato.

Scegliere per scenario

Scenario Modello consigliato dettagli
Sviluppatore indie che pubblica sul Microsoft Store Pacchetto (MSIX) consigliato MSIX è il percorso consigliato, che abilita gli aggiornamenti gestiti dallo Store, i download differenziali e la disinstallazione pulita. Le app WinUI 3 sono in pacchetto per impostazione predefinita. La firma del codice viene gestita gratuitamente dallo Store. → Distribuire l'app in pacchetto

Le app Win32 con un programma di installazione MSI o EXE esistente possono anche pubblicare nello Store tramite il percorso di invio MSI/EXE, ma lo Store non esegue il push degli aggiornamenti agli utenti esistenti. Gli aggiornamenti devono essere gestiti dall'app o dal programma di installazione.
App aziendale distribuita tramite Intune o Gestione configurazione Percorso pacchettizzato o esterno per i programmi di installazione esistenti Le nuove app devono usare MSIX. Le app esistenti con un proprio programma di installazione possono usare il packaging con la posizione esterna. Code signing: usare un certificato autofirmato (considerato attendibile tramite Intune, Criteri di gruppo o Gestione configurazione) oppure Azure Artifact Signing (precedentemente Trusted Signing). Distribuire applicazioni pacchettizzate
ISV che fornisce un download diretto con il proprio programma di installazione Confezionamento con ubicazione esterna Registrare un pacchetto di identità leggero insieme al programma di installazione esistente. Firma del codice: è necessario un certificato attendibile della CA per la distribuzione non nello Store. Firma degli Artefatti di Azure (precedentemente Firma Attendibile) è l'opzione più economica consigliata. Assegnare l'identità del pacchetto

In alternativa, inviare il programma di installazione esistente allo Store tramite il percorso di invio MSI/EXE.
Strumento interno o utilità per sviluppatori Unpackaged Più semplice da compilare e distribuire. Il SDK per app di Windows funziona tramite NuGet, ma alcune funzionalità non saranno disponibili.

Suggerimento

Non si è certi dei costi di firma del codice? La pubblicazione di un pacchetto MSIX tramite il Microsoft Store significa che non è necessario ottenere o gestire separatamente un certificato per l'attendibilità presso l'utente finale; Microsoft rifirma il pacchetto. La pubblicazione di un programma di installazione MSI/EXE Win32 tramite lo Store richiede una concatenazione di certificati a una CA nel Microsoft Trusted Root Program; un certificato autofirmato non è accettato. Per altri percorsi di distribuzione, l'approccio di firma dipende dal contesto di distribuzione: gli ambienti aziendali possono considerare attendibile un certificato autofirmato tramite la gestione dei dispositivi, mentre la distribuzione non store più ampia richiede in genere una soluzione di firma del codice attendibile della CA. Azure Firma Artefatto (in precedenza Firma Attendibile) è l'opzione consigliata da Microsoft (vedere pricing), senza alcuna necessità di token hardware.

Distribuzione dipendente dal framework vs distribuzione autonoma

Separatamente dal modello di creazione del pacchetto, le app che usano il SDK per app di Windows scelgono come gestire le dipendenze di runtime:

  • Framework-dependent: il runtime di SDK per app di Windows deve essere installato sulla macchina dell'utente. Footprint dell'app più piccola; si basa sul runtime presente o installazione automatica.
  • Self-contained: tutti i file binari SDK per app di Windows vengono forniti con l'app. Footprint più grande; nessun requisito di runtime esterno. Valido per gli ambienti aziendali bloccati.

→ Distribuire app autonome

Inizia con MSIX

Se crei un'app desktop Win32 (talvolta denominata app desktop classic desktop) o un'app .NET, inclusa Windows Presentation Foundation (macchine virtuali Windows) e Windows Forms (WinForms), puoi creare un pacchetto e distribuire l'app usando MSIX.

Altre tecnologie di installazione

Contenuti correlati

  • Last updated on