Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Annotazioni
Creazione di una nuova app WinUI 3? Per impostazione predefinita, l'utente è già incluso nel pacchetto. Questa pagina è destinata agli sviluppatori che devono effettuare una scelta esplicita, in genere durante la conversione di un'app esistente, la distribuzione nei computer aziendali o l'aggiunta di funzionalità di Windows a un'app che non è stata originariamente inserita in un pacchetto.
Le app di Windows possono essere pacchettizzate, non pacchettizzate, o una via di mezzo. La scelta giusta dipende da due aspetti: come si distribuisce l'app e quali funzionalità di Windows sono necessarie.
Inizia con il tuo scenario
Sono uno sviluppatore indipendente che pubblica sul Microsoft Store.
Usare un'applicazione MSIX pacchettizzata. Lo Store richiede pacchetti MSIX. Le app WinUI 3 create in Visual Studio sono incluse in pacchetti per impostazione predefinita. Non è necessario apportare modifiche. Si ottiene un'installazione pulita, gli aggiornamenti automatici e l'accesso a tutte le funzionalità di package-identity-gated, ad esempio notifiche e attività in background.
→ Distribuire l'app in pacchetto
"Sto creando un'app aziendale distribuita tramite Intune o Configuration Manager"
Avvia il pacchetto; considera un percorso esterno se hai un programma di installazione già esistente.
- Se si sta creando una nuova app, usare MSIX. Si integra in modo pulito con Intune e SCCM/ConfigMgr e offre un'identità completa del pacchetto.
- Se hai un'app esistente con il proprio programma di installazione che non puoi sostituire, usa la creazione di pacchetti con la posizione esterna. In questo modo, la tua app acquisisce un'identità del pacchetto e l'accesso a funzionalità come le notifiche e le attività in background, senza cambiare il modo o il luogo in cui viene distribuita.
- Se la tua app non ha realmente bisogno delle funzionalità che richiedono un'identità Windows e gestisci l'ambiente di distribuzione, lavorare senza pacchetto funziona, ma incontrerai difficoltà la prima volta che cercherai di aggiungere notifiche o funzionalità di intelligenza artificiale.
Distribuire app pacchettizzate (Windows App SDK)
Concedere l'identità del pacchetto tramite impacchettamento con localizzazione esterna
Sono un ISV che distribuisce un download diretto con il proprio programma di installazione.
Usare imballaggio con posizione esterna (in precedenza denominati pacchetti diradati).
Questo è il punto ideale per le app Win32/WPF/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 insieme al programma di installazione esistente, i file binari rimangono dove si trovano e si sblocca il set completo di funzionalità di Windows con controllo dell'identità del pacchetto.
Gli utenti non vedranno alcuna modifica nel modo in cui installano o aggiornano l'app. Si ottengono le funzionalità di Windows; ottengono un'esperienza familiare.
→ Concedere l'identità del pacchetto tramite creazione di pacchetti con posizione esterna
→ Aggiungere un pacchetto di identità in Visual Studio
"Sto creando uno strumento interno o un'utilità per sviluppatori"
Unpackaged va bene, con avvertenze.
Le app non in pacchetto sono la più semplice da compilare e distribuire: xcopy, robocopy o uno script semplice è tutto ciò che serve. Windows App SDK funziona in app non incluse in pacchetti tramite NuGet. Tuttavia, alcune funzionalità non saranno disponibili e, se successivamente si decide che sono necessarie, l'integrazione dell'identità del pacchetto sarà complessa.
Prima di impegnarsi a non confezionato, confrontare la tabella delle funzionalità seguente rispetto alla vostra 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.
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 |
Funzionalità che richiedono l'identità del pacchetto
Queste funzionalità di Windows funzionano solo nelle app con identità del pacchetto, tramite pacchetti MSIX completi o pacchetti con posizione esterna.
| Feature | Note |
|---|---|
| Notifiche dell'app (toast) |
AppNotificationManager richiede l'identità del pacchetto |
| Attività in background | La registrazione richiede l'identità del pacchetto |
| API windows per intelligenza artificiale (Phi Silica, OCR e così via) | La maggior parte delle API di intelligenza artificiale Windows richiede l'identità del pacchetto |
| Notifiche push (WNS) | La registrazione del canale richiede l'identità del pacchetto |
| Condividi destinazione | Dichiarato nel manifesto del pacchetto |
| Estensioni del menu di scelta rapida personalizzate | Dichiarato nel manifesto del pacchetto |
| Associazioni di tipo e protocollo di file | Le associazioni ricche richiedono l'identità del pacchetto |
| Attività di avvio | Richiede l'identità del pacchetto |
| Servizi app | Richiede l'identità del pacchetto |
Suggerimento
Se il pacchetto non è installato e si verificano errori E_ILLEGAL_METHOD_CALL o APPMODEL_ERROR_NO_PACKAGE quando si chiamano le API di Windows, ciò è dovuto al requisito di identità del pacchetto. Vedere l'imballaggio con ubicazione esterna come la soluzione con meno attrito.
Confezionamento con ubicazione esterna
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).
Fornisci:
- Un manifesto del pacchetto (file XML che descrive l'identità dell'app)
- Oggetto firmato
.msixcontenente solo il manifesto (nessun file binario)
Il programma di installazione esistente registra questo pacchetto di identità e Windows considera l'applicazione come avente l'identità di pacchetto a partire da quel momento.
Questo è diverso dal pacchetto MSIX completo:
| 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 |
Distribuzione dipendente dal framework vs distribuzione autonoma
Separatamente dal modello di creazione del pacchetto, le app che usano Windows App SDK scelgono come gestire le dipendenze di runtime:
- Dipendente dal framework: il runtime di Windows App SDK deve essere installato nel computer dell'utente. Footprint dell'app più piccola; si basa sul runtime presente o installazione automatica.
- Indipendente: tutti i file binari di Windows App SDK vengono forniti con l'app. Footprint più grande; nessun requisito di runtime esterno. Valido per gli ambienti aziendali bloccati.
Contenuti correlati
Collabora con noi su GitHub
L'origine di questo contenuto è disponibile in GitHub, in cui è anche possibile creare ed esaminare i problemi e le richieste pull. Per ulteriori informazioni, vedere la guida per i collaboratori.
