Panoramica della distribuzione di SDK per app di Windows

Esistono due modi in cui è possibile distribuire il SDK per app di Windows:

  • dipendente dal framework. L'app dipende dal runtime di SDK per app di Windows e/o dal pacchetto framework presente nel computer di destinazione. La distribuzione dipendente dal framework è la modalità di distribuzione predefinita del SDK per app di Windows per un uso efficiente delle risorse del computer e della gestibilità.
  • completamente autonomo. L'app porta con sé le dipendenze di SDK per app di Windows, eliminando la necessità di un'installazione separata del runtime sul computer di destinazione.

Questo argomento usa anche i termini app in pacchetto, app in pacchetto con posizione esterna e app non in pacchetto. Per spiegazioni di questi termini, vedere Panoramica della distribuzione.

Distribuire dipendente dal framework Distribuire autosufficiente
Vantaggi Distribuzione di piccole dimensioni. Vengono distribuite solo l'applicazione e le sue altre dipendenze. Il SDK per app di Windows runtime e il pacchetto Framework vengono installati automaticamente da app dipendenti dal framework incluse in un pacchetto o come parte del programma di installazione di runtime SDK per app di Windows da app dipendenti dal framework incluse in un pacchetto con percorso esterno o senza pacchetti.

Utilizzabile. Gli aggiornamenti di manutenzione al SDK per app di Windows vengono installati automaticamente tramite il pacchetto SDK per app di Windows Framework senza alcuna azione necessaria per l'app.		 Controllo della versione di SDK per app di Windows. Puoi controllare la versione del SDK per app di Windows distribuita con l'app. Gli aggiornamenti di manutenzione del SDK per app di Windows non influisce sull'app a meno che non lo ricompila e ridistribuisci.

Isolato da altre app. Le app e gli utenti non possono disinstallare la dipendenza SDK per app di Windows senza disinstallare l'intera app.

Distribuzione di Xcopy. Poiché le dipendenze di SDK per app di Windows sono incluse nella tua app, puoi distribuire l'app semplicemente copiando l'output della compilazione, senza requisiti di installazione aggiuntivi.
Svantaggi Dipendenze di installazione aggiuntive. Richiede l'installazione del runtime di SDK per app di Windows e/o del pacchetto Framework, che può aggiungere complessità all'installazione dell'app.

Dipendenze condivise. Rischio che le dipendenze condivise vengano disinstallate. Le app o gli utenti che disinstallano i componenti condivisi possono influire sull'esperienza utente di altre app che condividono la dipendenza.

Rischio di compatibilità. Rischio che la manutenzione degli aggiornamenti al SDK per app di Windows introduca modifiche di rilievo. Anche se gli aggiornamenti di manutenzione devono garantire la compatibilità con le versioni precedenti, è possibile che vengano introdotte le regressioni.		 Distribuzioni più grandi (solo app non in pacchetto). Poiché l'app include il SDK per app di Windows, le dimensioni del download e lo spazio su disco rigido necessari sono maggiori di quanto sarebbe il caso per una versione dipendente dal framework.

Prestazioni (solo app non in pacchetto). Più lento da caricare e usa più memoria perché le pagine di codice non vengono condivise con altre app.

Non utilizzabile. La versione SDK per app di Windows distribuita con l'app può essere aggiornata solo rilasciando una nuova versione dell'app. L'utente è responsabile dell'integrazione degli aggiornamenti di manutenzione dei SDK per app di Windows nell'app.

Vedi anche Crea il tuo primo progetto WinUI 3 e Usa il SDK per app di Windows in un progetto esistente.

Annotazioni

PublishSingleFile (EXE a file singolo) è supportato per le app WinUI 3 indipendenti senza pacchetti (SDK per app di Windows 1.5 e versioni successive). Le app in pacchetto e le app dipendenti dal framework non supportano PublishSingleFile. Per le proprietà di MSBuild necessarie, vedere EXE a file singolo .

Altre informazioni sulla distribuzione dipendente dal framework

Prima di configurare l'app dipendente dal framework per la distribuzione, per ulteriori informazioni sulle dipendenze dell'app quando utilizza il SDK per app di Windows, consultare Architettura di distribuzione per il SDK per app di Windows.

Applicazioni confezionate

Se si è scelto di usare un'app in pacchetto dipendente dal framework (vedere panoramica di Deployment), ecco le istruzioni su come distribuire il runtime SDK per app di Windows con l'app:

Imballato con posizione esterna o app non imballate

Se si è scelto di usare un'app in pacchetto dipendente dal framework con posizione esterna o un'app non in pacchetto dipendente dal framework (vedere Panni preliminari sulla distribuzione), ecco le istruzioni su come distribuire il runtime di SDK per app di Windows con l'app:

Altre informazioni sulla distribuzione autonoma

Vedere SDK per app di Windows guida alla distribuzione per le app autonome.

Annotazioni

PublishSingleFile (EXE in un unico file) richiede che l'app sia sia senza pacchetto sia autonoma. Vedere File singolo EXE per l'elenco completo delle proprietà MSBuild necessarie.

Inizializzare il SDK per app di Windows

Il modo in cui devi inizializzare il SDK per app di Windows dipende dal fatto che e come creare il pacchetto dell'app e dalla modalità di distribuzione rispetto al runtime di SDK per app di Windows. Utilizza la sezione seguente che si applica alla tua app.

Applicazioni confezionate

Modalità di distribuzione dell'app Come inizializzare
Dipendente dal framework Fare riferimento a Consultare l'API di distribuzione.
Autosufficiente Nessuna inizializzazione necessaria.

App non in pacchetto e app in pacchetto con posizione esterna

Modalità di distribuzione dell'app Come inizializzare
Dipendente dal framework Consultare Usare l'API del bootstrapper in un'app confezionata con percorso esterno o non impacchettata.
Autosufficiente Per ulteriori informazioni, vedere rinuncia a (o aderire a) il supporto automatico di UndockedRegFreeWinRT.

Considerazioni sull'architettura (x64, ARM64)

Quando si distribuisce l'app, è necessario includere file binari per ogni architettura del processore necessaria agli utenti. Questo vale sia per le modalità di distribuzione dipendenti dal framework che per le modalità di distribuzione autonome.

Supporto per ARM64

Windows nei dispositivi ARM (inclusi Surface Pro X, Surface Pro 11 e Copilot+ PCs) eseguono ARM64 in modo nativo. Anche se l'emulazione x64 è disponibile nei dispositivi ARM64 Windows 11, i file binari ARM64 nativi offrono prestazioni e durata della batteria migliori e sono consigliati quando si vuole ottenere un'esperienza ottimale per i carichi di lavoro di intelligenza artificiale sul dispositivo in Copilot+ PCs.

Distribuzione di ARM64 nativa

  • Bundle MSIX — Creare .msixbundle che includa le architetture x64 e ARM64. Visual Studio genera questi automaticamente quando si compila per più piattaforme. Il programma di installazione dello Store e dell'app seleziona l'architettura corretta in fase di installazione.

  • Pubblicazione autonoma : specificare l'identificatore di runtime (RID) per ogni architettura:

    dotnet publish -c Release -r win-x64 --self-contained true
dotnet publish -c Release -r win-arm64 --self-contained true

  • C++/WinRT: creare configurazioni separate per x64 e ARM64 nella soluzione Visual Studio.

  • Applicazioni dipendenti dal framework — Quando si utilizza il programma di installazione del runtime di SDK per app di Windows, assicurarsi di fornire il programma di installazione corretto per l'architettura specifica. Il SDK per app di Windows include programmi di installazione separati per x64 e ARM64.

Arm64EC : migrazione graduale per codebase C/C++ di grandi dimensioni

Se l'app ha una codebase nativa di grandi dimensioni (C/C++), una ricompilazione completa per ARM64 potrebbe non essere pratica in un unico passaggio. Arm64EC (compatibile con emulazione) consente di combinare codice x64 e ARM64 nello stesso processo. È possibile ricompilare i moduli critici per le prestazioni in ARM64 nativo mentre i moduli x64 rimanenti vengono eseguiti in emulazione, tutti all'interno di un singolo file binario.

Avvicinarsi Migliore per Compromesso
Ricompilazione ARM64 completa App .NET pure, piccoli progetti C++ Migliori prestazioni; richiede che tutte le dipendenze siano compatibili con ARM64
Arm64EC App C/C++ di grandi dimensioni, app con plug-in solo x64 o DLL di terze parti Migrazione incrementale; le parti emulate girano più lentamente rispetto alle parti native
Solo x64 (in emulazione) App che non possono essere ricompilate e che non richiedono prestazioni di picco Semplice; riduzione della durata della batteria e maggiore latenza nei dispositivi ARM64

Per altre informazioni, vedere Arm64EC - Compilare e convertire app per prestazioni native in Arm.

Emulazione (Prism)

Windows 11 su ARM usa un livello di emulazione denominato Prism per eseguire app x64 e x86 nell'hardware ARM64. Prism converte le istruzioni x86/x64 in ARM64 in fase di esecuzione, offrendo un'ampia compatibilità delle app senza richiedere una ricompilazione.

  • Emulazione x64: disponibile solo nei dispositivi ARM64 Windows 11 (non Windows 10 su ARM).
  • Emulazione x86: disponibile sia nei dispositivi Windows 10 che in Windows 11 ARM64.
  • Prestazioni : le app emulate vengono in genere eseguite con prestazioni accettabili per i carichi di lavoro di produttività, ma le app a elevato utilizzo di grafica o calcolo traggono vantaggio in modo significativo da una build ARM64 o Arm64EC nativa.

Suggerimento

Se la destinazione è solo x64, l'app viene comunque eseguita nei dispositivi ARM64 tramite emulazione prism (solo Windows 11). Tuttavia, le build NATIVE ARM64 sono fortemente consigliate per le app di produzione: le app emulate usano più batteria e hanno una latenza più elevata. In Copilot+ PCs, ARM64 nativo può offrire prestazioni ottimali per i carichi di lavoro di intelligenza artificiale sul dispositivo.

Per l'invio allo Store, carica pacchetti specifici per l'architettura o un bundle che li contenga entrambi. Lo Store fornisce solo l'architettura corrispondente a ogni dispositivo.

  • Last updated on