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.
Per impostazione predefinita, un progetto di SDK per app di Windows dipende dal framework. Per passare alla distribuzione autonoma, seguire questa procedura (i termini dipendenti dal framework e autonomo sono descritti in panoramica della distribuzione di SDK per app di Windows).
- In Visual Studio fare clic con il pulsante destro del mouse sul nodo del progetto dell'app e scegliere Modifica file di progetto per aprire il file di progetto dell'app per la modifica. Per un progetto C++, fare prima clic su Scarica progetto.
- Nel file di progetto dell'app, all'interno del
PropertyGroup
principale, aggiungere<WindowsAppSDKSelfContained>true</WindowsAppSDKSelfContained>
come illustrato nello screenshot seguente.
- Salva e chiudi il file di progetto.
- Fare clic su Ricarica progetto.
- Se si utilizza un progetto di creazione pacchetti di applicazioni Windows (anziché il progetto singolo MSIX che si ottiene con App vuota, In pacchetto (WinUI 3 in Desktop)), apportare anche tutte le modifiche precedenti nel file di progetto del progetto di creazione del pacchetto.
Nota
I progetti di librerie non devono essere modificati. La distribuzione autonoma deve essere configurata solo nei progetti di app (e, ove applicabile, in un progetto di creazione pacchetti di applicazioni Windows).
Per le app di esempio, vedere esempi di distribuzione autonoma di SDK per app di Windows.
Dopo aver impostato la WindowsAppSDKSelfContained
proprietà su true
nel file di progetto, il contenuto del pacchetto di Framework SDK per app di Windows verrà estratto nell'output di compilazione e distribuito come parte dell'applicazione.
Nota
Le app .NET devono essere pubblicate come autonome per essere completamente autonome. Ecco questo esempio per vedere come configurare .NET self-contained con i profili di pubblicazione.
dotnet publish
non è ancora supportato con SDK per app di Windows 1.1.
Nota
Le app C++ devono usare anche CRT ibrido per essere completamente autonome. L'importazione di HybridCRT.props da Directory.Build.props è il modo consigliato per configurarla per tutti i progetti in una soluzione (vedere un esempio in Directory.Build.props). Un'app pacchettizzata deve anche impostare <UseCrtSDKReferenceStaticWarning>false</UseCrtSDKReferenceStaticWarning>
nel proprio file di progetto. Per sapere come utilizzare il CRT ibrido, vedere l'app di esempio di distribuzione autonoma.
Se l'app è inclusa in un pacchetto (per altre informazioni, vedere Panoramica della distribuzione), le dipendenze SDK per app di Windows verranno incluse come contenuto all'interno del pacchetto MSIX. La distribuzione dell'app richiede comunque la registrazione del pacchetto MSIX come qualsiasi altra app in pacchetto.
Se l'app viene inserita in un pacchetto con percorso esterno o senza pacchetti, le dipendenze SDK per app di Windows vengono copiate accanto a .exe
nell'output di compilazione. È possibile sottoporre a distribuzione (xcopy) i file risultanti o includerli in un programma di installazione personalizzato.
Dipendenze da pacchetti MSIX aggiuntivi
Un numero ridotto di API nella SDK per app di Windows si basa su pacchetti MSIX aggiuntivi che rappresentano funzionalità critiche del sistema operativo.
- Ad esempio (a partire dall'SDK per app di Windows 1.1), le API di notifica push (PushNotificationManager) e le API di notifica app (AppNotificationManager) presentano una dipendenza sul pacchetto Singleton (vedere Architettura di distribuzione per l'SDK per app di Windows).
Ciò significa che se si vuole utilizzare queste API in un'app autonoma, si hanno le opzioni seguenti:
- È possibile rendere facoltativa la funzionalità e ottimizzarla solo se e quando possibile. Chiamando il metodo IsSupported dell'API (PushNotificationManager.IsSupported e AppNotificationManager.IsSupported) sarà possibile controllare in modo dinamico in fase di esecuzione se le API sono disponibili per l'app chiamante nel sistema su cui è in esecuzione.
- Ciò consente l'uso sicuro, condizionale e facoltativo delle API senza compromettere la semplicità della distribuzione autonoma.
- Solo se i servizi del sistema operativo vengono installati all'esterno della distribuzione dell'app, l'app ottimizzerà le funzionalità appropriate. Tuttavia, esistono alcuni casi in cui le API funzioneranno anche senza che il pacchetto Singleton sia presente, quindi chiamare IsSupported per controllare è spesso una buona idea.
- Distribuire i pacchetti MSIX necessari come parte dell'installazione dell'app.
- Ciò consente di dipendere dall'API in tutti gli scenari. Tuttavia, la distribuzione di pacchetti MSIX per le dipendenze come parte della distribuzione dell'app può compromettere la semplicità dell'installazione autonoma.
- Non utilizzare l'API.
- Prendere in considerazione API alternative che forniscono funzionalità simili senza requisiti di distribuzione aggiuntivi.
Escludersi (o includersi) nel supporto automatizzato di UndockedRegFreeWinRT.
La proprietà del progetto WindowsAppSdkUndockedRegFreeWinRTInitialize è stata introdotta nella versione 1.2 dell'SDK per app di Windows (dal canale stabile). Se tale proprietà è impostata su vero, garantisce che l'implementazione di Windows App SDK di Windows Runtime senza registrazione (UndockedRegFreeWinRT) venga abilitata automaticamente all'avvio dell'app. Tale supporto è necessario per le app indipendenti senza pacchetti.
L'impostazione predefinita di WindowsAppSdkUndockedRegFreeWinRTInitialize è vero se WindowsAppSDKSelfContained è vero e WindowsPackageType è Nessuno e (a partire dalla versione 1.2 del SDK per app di Windows) la proprietà di progetto OutputType è impostata su Exe o WinExe (ovvero il progetto produce un eseguibile). L'ultima condizione consiste nell'impedire l'aggiunta del supporto automatico UndockedRegFreeWinRT nelle DLL della libreria di classi e in altri file non eseguibili per impostazione predefinita. Se è necessario il supporto automatico UndockedRegFreeWinRT in un elemento non eseguibile, ad esempio una DLL di test caricata da un eseguibile del processo host che non inizializza UndockedRegFreeWinRT, è possibile abilitarla in modo esplicito nel progetto con <WindowsAppSdkUndockedRegFreeWinRTInitialize>true</WindowsAppSdkUndockedRegFreeWinRTInitialize>
.