Condividi tramite

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 packaging con posizione esterna (creazione di pacchetti sparse).

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 è impacchettati e si incontrano errori E_ILLEGAL_METHOD_CALL o APPMODEL_ERROR_NO_PACKAGE quando si chiamano API di Windows, allora è una questione del 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ì Nuove app, pubblicazione nello Store, MDM aziendale
Creazione di pacchetti con posizione esterna ✅ Sì Programma di installazione esistente ❌ No App esistenti con programma di installazione proprio, ISV
Non confezionato ❌ No XCopy/script ❌ No Strumenti interni, utilità di sviluppo, scenari semplici

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ì No
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 su Microsoft Store Pacchetto (MSIX) Lo Store richiede MSIX. Le app WinUI 3 sono in pacchetto per impostazione predefinita: non sono necessarie modifiche. → Distribuire l'app in pacchetto
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. 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. Gli utenti non vedono alcuna modifica; si ottengono Windows funzionalità. Assegnare l'identità del pacchetto
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.

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 nel computer 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