Note sulla versione del canale di anteprima per Windows App SDK 1.0

  • Articolo

Importante

Il canale anteprima non è supportato per l'uso negli ambienti di produzione e le app che utilizzano i rilasci sperimentali non possono essere pubblicati nel Microsoft Store.

Il canale di anteprima include le versioni di Windows AppSDK con funzionalità del canale di anteprima nelle ultime fasi di sviluppo. Le versioni di anteprima non includono funzionalità sperimentali e API, ma potrebbero comunque essere soggette a modifiche di rilievo prima della prossima versione stabile.

Collegamenti importanti:

Ultime note sulla versione del canale di anteprima:

Ultime note sulla versione del canale Stabile

Versione 1.0 Anteprima (1.0.0-preview3)

La Preview 3 è la versione più recente del canale di anteprima per la versione 1.0 di Windows App SDK. L'anteprima 3 supporta tutte le funzionalità del canale di anteprima.

Scaricare le estensioni di Visual Studio 1.0 Preview 3 (VSIX)

Nota

Se sono state installate le estensioni di Visual Studio (VSIX) di Windows App SDK, disinstallarle prima di installare una nuova versione. Per le direzioni, vedere Gestisci estensioni per Visual Studio.

Dalla tabella seguente è possibile scaricare le estensioni di Visual Studio (VSIX) per la versione 1.0 Preview 3. Per tutte le versioni, consultare la sezione Ultimi download di Windows App SDK. Se non è già stato fatto, iniziare configurando l'ambiente di sviluppo seguendo la procedura descritta in Installazione degli strumenti per Windows App SDK.

Le estensioni seguenti sono personalizzate per il linguaggio di programmazione e la versione di Visual Studio.

Download di 1.0 Preview 3 Descrizione
Estensione di Visual Studio 2019 C# Compilare app C# con l'estensione di Visual Studio 2019 per Windows App SDK.
Estensione di Visual Studio 2019 C++ Compilare app C# con l'estensione di Visual Studio 2019 per Windows App SDK.
Estensione di Visual Studio 2022 C# Compilare app C# con l'estensione di Visual Studio 2022 per Windows App SDK.
Estensione di Visual Studio 2022 C++ Compilare app C# con l'estensione di Visual Studio 2022 per Windows App SDK.
Il .exe programma di installazione e i pacchetti MSIX Distribuire Windows App SDK con l'app usando il .exe programma di installazione e i pacchetti MSIX.

Nelle sezioni seguenti vengono descritte le funzionalità nuove e aggiornate, le limitazioni e i problemi noti per 1.0 Preview 3.

WinUI 3 (1.0.0-preview3)

Ora è supportata la distribuzione di app WinUI 3 senza pacchetti MSIX. Consultare la sezione Creazione del primo progetto WinUI 3 (Windows App SDK) per configurare l'applicazione WinUI 3 in modo da supportare la distribuzione non inclusa nel pacchetto.

Limitazioni importanti:

  • Le applicazioni WinUI 3 non incluse nel pacchetto sono supportate solo nelle versioni di Windows 1909 e successive.
  • Le applicazioni WinUI 3 non incluse nel pacchetto sono supportate in x86 e x64. Il supporto arm64 verrà aggiunto nella prossima versione stabile.
  • L'estensione Strumenti di creazione pacchetti MSIX a progetto singolo per Visual Studio 2019 o Visual Studio 2022 è necessaria per le app non incluse nel pacchetto.
  • In un'app non inclusa nel pacchetto potrebbe essere visualizzato un prompt per installare .NET 3.5; se viene fatto, è possibile ignorarlo.
  • Alcune API non sono attualmente supportate nelle app non incluse nel pacchetto. L'obiettivo è risolvere questo problema nella prossima versione stabile. Alcuni esempi:
  • I controlli ListView, CalendarView e GridView usano gli stili non corretti, per cui stiamo cercando di risolvere questo problema nella prossima versione stabile.

Per altre informazioni o per iniziare a sviluppare con WinUI 3, vedere:

Altre limitazioni e problemi noti:

  • Le app non incluse nel pacchetto non sono supportate in Windows 10 versione 1809. L'obiettivo è risolvere questo problema nella versione successiva nel canale stabile.

  • L'app MSIX a progetto singolo C# non viene compilata se gli strumenti UWP C++ non sono installati. Se si dispone di un progetto MSIX a progetto singolo C#, sarà necessario installare il componente facoltativo C++ (v14x) Strumenti per la piattaforma UWP (Universal Windows Platform).

  • Questa versione presenta i modelli di progetto App vuota, In pacchetto (WinUI 3 in Desktop) per C# e C++. Questi modelli consentono di compilare l'app in un pacchetto MSIX senza l'uso di un progetto separato di creazione pacchetti (vedere Creazione di un pacchetto dell'app usando MSIX a progetto singolo). Questi modelli presentano alcuni problemi noti in questa versione:

    • Voce di menu Pubblica mancante fino al riavvio di Visual Studio. Quando si crea una nuova app sia in Visual Studio 2019 che in Visual Studio 2022 usando il modello di progetto App vuota, Inclusa nel pacchetto (WinUI 3 in Desktop), il comando per pubblicare il progetto non viene visualizzato nel menu finché non si chiude e si riapre Visual Studio.

    • Errore durante l'aggiunta di riferimenti a progetti di libreria statica/dinamica alle app C++ usando la creazione di pacchetti MSIX a progetto singolo. Visual Studio visualizza un errore indicante che il progetto non può essere aggiunto come riferimento poiché i tipi di progetto non sono compatibili.

    • Errore durante il riferimento a un controllo utente personalizzato in un progetto di libreria di classi. L'applicazione si arresterà in modo anomalo riportando l'errore che il sistema non riesce a trovare il percorso specificato.

    • Modello C# o C++ per Visual Studio 2019. L'errore si verificherà quando si tenta di compilare il progetto: "Il progetto non sa come eseguire il nome progetto del profilo". Per risolvere questo problema, installare l'estensione Strumenti di creazione pacchetti MSIX a progetto singolo.

    • Modello C# per Visual Studio 2019 e Visual Studio 2022. In Visual Studio quando si usa Avvia il Debug o Avvia senza eseguire il debug, se l'app non viene distribuita ed eseguita (e non sono presenti commenti e suggerimenti da Visual Studio), fare clic sul nodo del progetto in Esplora soluzioni per selezionarla e riprovare.

    • Modello C# per Visual Studio 2019 e Visual Studio 2022. Quando si tenta l'esecuzione o si tenta di eseguire il debug del progetto nel computer di sviluppo, si verifica l'errore seguente: "Il progetto deve essere distribuito prima di poter eseguire il debug. Abilitare Distribuisci in Configuration Manager." Per risolvere questo problema, abilitare la distribuzione per il progetto in Configuration Manager. Per istruzioni dettagliate, consultare la sezione Creazione del primo progetto WinUI 3 (Windows App SDK).

    • Modello C++ per Visual Studio 2022 versione 17.0 fino alla Preview 4. Si verifica il seguente errore la prima volta che si tenta di eseguire il progetto: "Si sono verificati errori di distribuzione". Per risolvere questo problema, eseguire o distribuire il progetto una seconda volta. Questo problema verrà risolto in Visual Studio 2022 versione 17.0 Preview 7.

  • Nessun supporto per qualsiasi configurazione di compilazione cpu: quando si aggiunge Windows App SDK a un'applicazione o a un componente .NET esistente che supporta Qualsiasi CPU, è necessario specificare l'architettura desiderata: x86 o x64 arm64.

  • +I progetti C# che usano la versione 1.0 Preview 3 devono usare il seguente .NET SDK: .NET 6 SDK o versione successiva (vedere Download .NET e .NET 5 raggiungeranno la fine del supporto il 10 maggio 2022).

  • Un'alternativa a DispatcherQueue.TryEnqueue (per riprendere l'esecuzione nel thread della coda del dispatcher) consiste nell'usare la funzione helper resume_foreground nella Libreria di implementazione di Windows (WIL):

    1. Per prima cosa, aggiungere un riferimento al progetto al pacchetto NuGet Microsoft.Windows.ImplementationLibrary.
    2. Aggiungere #include <wil/cppwinrt_helpers.h> al proprio pch.h.
    3. Aggiungere #include <winrt/Microsoft.UI.Dispatching.h> al proprio pch.h.
    4. Ora co_await wil::resume_foreground(your_dispatcherqueue);.

Problema importante che influisce sulla versione 1.0 Preview 1 e Preview 2

La versione 1.0 Preview 1 e l'anteprima 2 di Windows App SDK include un meccanismo per pulire tutte le modifiche delle variabili di ambiente apportate da un'app inclusa nel pacchetto quando tale app viene disinstallata. Questa funzionalità si trova in uno stato sperimentale e la prima versione include un bug noto che può danneggiare la variabile di ambiente PATH del sistema.

Preview 1 e Preview 2 danneggiano qualsiasi variabile di ambiente PATH contenente il carattere di espansione %. Ciò si verifica ogni volta che viene disinstallata un'app in pacchetto, indipendentemente dal fatto che l'app usi Windows App SDK.

Vedere anche il problema di danneggiamento delle variabili di ambiente PATH.

Dettagli

La voce di sistema PATH viene archiviata nel valore Path nella chiave seguente nel Registro di sistema:

Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment

Se si avvia l'editor del Registro di sistema (regedit.exe), è possibile copiare e incollare il percorso sopra nella barra di navigazione (immediatamente sotto la barra dei menu) e premere INVIO per individuare il tasto.

Il valore Path di tale chiave dovrebbe essere di tipo REG_EXPAND_SZ, ma il bug lo modifica in REG_SZ. Ciò rende inutilizzabile la variabile dell'ambiente di sistema PATH se contiene il carattere di espansione della variabile %.

Versioni interessate

Strategia di riduzione del rischio

Per ripristinare lo stato corretto del computer, seguire questa procedura:

  1. Controllare se PATH nel Registro di sistema è danneggiato e, in tal caso, reimpostarlo eseguendo lo script seguente.

    È possibile eseguire il passaggio 1 con il seguente script di Windows PowerShell (PowerShell Core non funzionerà). Eseguirlo con privilegi elevati.

    # This script must be run from an elevated Windows PowerShell
# window (right-click Windows PowerShell in the Start menu,
# and select Run as Administrator).

# If the PATH in the Registry has been set to REG_SZ, then delete
# it, and recreate it as REG_EXPAND_SZ.

$EnvPath = 'Registry::HKLM\System\CurrentControlSet\Control\Session Manager\Environment'
$Environment=Get-Item $EnvPath
$PathKind = $Environment.GetValueKind('Path')

if ($PathKind -ne 'ExpandString') {
  $Path = $Environment.GetValue('Path')
  Remove-ItemProperty $EnvPath -Name Path
  New-ItemProperty $EnvPath -Name Path -PropertyType ExpandString -Value $Path
}

  2. Disinstallare tutte le app che usano Windows App SDK 1.0 Preview1 o Preview2 (vedere lo script seguente).

  3. Disinstallare i pacchetti Windows App SDK 1.0 Preview1/Preview2, incluso il pacchetto che contiene il bug (vedere lo script seguente).

    È possibile eseguire i passaggi 2 e 3 con il seguente script di Windows PowerShell (PowerShell Core non funzionerà). Eseguirlo con privilegi elevati.

    # This script must be run from an elevated Windows PowerShell
# window (right-click Windows PowerShell in the Start menu,
# and select Run as Administrator).

# Remove the Windows App SDK 1.0 Preview1/2, and all apps that use it.

$winappsdk = "Microsoft.WindowsAppRuntime.1.0-preview*"
Get-AppxPackage | Where-Object { $_.Dependencies -like $winappsdk } | Remove-AppxPackage
Get-AppxPackage $winappsdk | Remove-AppxPackage

Correzione in Windows App SDK 1.0 Preview 3

La funzionalità che causa il danneggiamento della variabile di ambiente PATH verrà rimossa nella versione successiva di Windows App SDK 1.0 Preview 3. Potrebbe essere reintrodotto in un secondo momento, quando tutti i bug sono stati corretti e testati accuratamente.

È consigliabile usare la versione 1.0 Preview 3.

Versione 1.0 Preview 2 (1.0.0-preview2)

Importante

La versione 1.0 Preview 1 e Preview 2 contiene un bug critico. Se è già stata installata una di queste anteprime, consultare la sezione Come risolvere il problema. È consigliabile usare invece la versione 1.0 Preview 3 .

Questa è l'ultima versione del canale di anteprima per la versione 1.0. Supporta tutte le funzionalità del canale di anteprima.

Nelle sezioni seguenti vengono descritte le funzionalità nuove e aggiornate, le limitazioni e i problemi noti di questa versione.

WinUI 3 (1.0.0-preview2)

Nuovi aggiornamenti:

  • I controlli sono stati aggiornati per riflettere gli stili di Windows più recenti di WinUI 2.6.
  • MSIX a progetto singolo è supportato.
  • Il pacchetto WinUI 3 può essere ora destinato alla build 17763 e versioni successive. Per altre informazioni, vedere il problema #921.
  • La barra strumenti in-app è supportata. Tuttavia, la barra degli strumenti in-app e il supporto esistente "Ricaricamento rapido/Albero visuale in tempo reale" richiedono la prossima versione di Visual Studio 17.0 Preview 5, disponibile più avanti in ottobre.

Correzione di bug: il testo WebView2Runtime è ora localizzato.

Per altre informazioni o per iniziare a sviluppare con WinUI 3, vedere:

Windowing (1.0.0-preview2)

Questa versione introduce gli aggiornamenti alla classe AppWindow . In questa versione non sono state aggiunte nuove funzionalità principali, ma sono state rimosse modifiche ai nomi dei metodi, alle proprietà e ad alcuni valori restituiti. Vedere la documentazione e gli esempi per gli aggiornamenti dettagliati. Se è stato usato AppWindow nelle versioni 1.0 Experimental or 1.0 Preview 1, occorre aspettarsi alcune modifiche al codice.

Nuovi aggiornamenti:

  • La classe AppWindowConfiguration è stata rimossa. Le proprietà di questa classe sono ora disponibili nella stessa AppWindow o nelle classi Relatore.
  • La maggior parte dei bool valori restituiti per i metodi API WinRT in questo spazio è stata rimossa ed è ora void poiché questi metodi hanno sempre esito positivo.
  • Le chiamate C# ImportDll non sono più necessarie per GetWindowIdFromWindow e GetWindowFromWindowId. Usare invece i metodi wrapper .NET disponibili nella classe Microsoft.UI.Win32Interop class instead.

Limitazioni importanti:

  • Al momento Windows App SDK non fornisce metodi per collegare il contenuto del framework dell'interfaccia utente a un AppWindow; è possibile usare solo i metodi di accesso di interoperabilità.
  • La personalizzazione della barra del titolo della finestra funziona solo in Windows 11. Usare il metodo IsCustomizationSupported per verificare il supporto delle funzionalità di personalizzazione della barra del titolo. L'intento è di portare questa funzionalità a un livello inferiore.

Per maggiori informazioni, consultare la sezione Gestione delle app Windows (Windows App SDK).

Input (1.0.0-preview2)

Nuovi aggiornamenti:

  • Miglioramento del supporto per l'input del touchpad di precisione.

Limitazioni importanti:

  • Tutte le funzioni statiche di fabbrica di PointerPoint sono state rimosse: GetCurrentPoint, GetCurrentPointTransformed, GetIntermediatePoints e GetIntermediatePointsTransformed.
  • Windows App SDK non supporta il recupero di oggetti PointerPoint con ID puntatore. È invece possibile utilizzare la funzione membro PointerPointGetTransformedPoint per recuperare una versione trasformata di un oggetto PointerPoint. Per i punti intermedi, è possibile utilizzare le funzioni membro PointerEventArgsGetIntermediatePoints e GetTransformedIntermediatePoints. Per ulteriori dettagli, vedere la documentazione.

MRT Core (1.0.0-preview2)

Nuovi aggiornamenti:

  • Gli sviluppatori di app possono ora rifiutare esplicitamente l'indicizzazione di un file di immagine o di un file RESW nel file PRI nei progetti .NET. Per altre informazioni, vedere il problema 980.

Limitazioni importanti:

  • Nei progetti .NET i file di risorse copiati nella cartella del progetto non vengono indicizzati in F5 se l'app è già stata compilata. Come soluzione alternativa, ricompilare l'app. Per altre informazioni, vedere il problema 1503 ].
  • Nei progetti .NET i file di risorse esistenti aggiunti da una cartella esterna non vengono indicizzati senza l'impostazione manuale dell'azione di compilazione. Per risolvere questo problema, impostare l'azione di compilazione in Visual Studio: Contenuto per i file di immagine e PRIResource per i file RESW. Per altre informazioni, vedere il problema 1504.

Distribuzione per app non in pacchetto

Nuove funzionalità:

  • Windows App SDK 1.0 Preview 2 introduce un wrapper .NET per l'API del programma di avvio automatico (vedere Utilizzo del runtime di Windows App SDK per le app incluse nel pacchetto con percorso esterno o non incluso nel pacchetto). L'API del programma di avvio automatico è un set di funzioni C/C++ native che le app non incluso nel pacchetto devono usare per assumere in modo dinamico una dipendenza dal pacchetto framework di Windows App SDK in fase di esecuzione. Il wrapper .NET offre un modo più semplice per richiedere l'API del programma di avvio automatico dalle app .NET, incluse le app Windows Form e WPF. Il wrapper .NET per l'API del programma di avvio automatico è disponibile nell'assembly Microsoft.WindowsAppRuntime.Bootstrap.Net.dll, che è locale per il progetto dell'app. Per altre informazioni sul wrapper .NET, vedere Libreria wrapper .NET.
  • Le app in pacchetto possono ora usare l'API di distribuzione per ottenere i pacchetti MSIX principali e singleton installati nel computer. I pacchetti main e singleton fanno parte del pacchetto framework installato con l'app, ma a causa di una limitazione con il modello di applicazione windows, le app incluse nel pacchetto dovranno eseguire questo passaggio aggiuntivo per ottenere tali pacchetti installati. Per altre informazioni sul funzionamento dell'API di distribuzione, vedere Windows App SDK: guida alla distribuzione per le app incluse nel pacchetto dipendenti dal framework.

Limitazioni importanti:

  • Il wrapper .NET per l'API del programma di avvio automatico è destinato solo alle applicazioni .NET senza pacchetti per semplificare l'accesso a Windows App SDK.
  • Solo le app MSIX incluse nel pacchetto con attendibilità totale o che dispongono della funzionalità con restrizioni packageManagement hanno l'autorizzazione per usare l'API di distribuzione per installare le dipendenze del pacchetto Main e Singleton. Il supporto per le app incluse nel pacchetto con attendibilità parziale sarà disponibile nelle versioni successive.
  • Quando F5 testa un'app x86 che usa il metodo DeploymentManager.Initialize in un sistema x64, verificare che il framework x64 sia installato per la prima volta eseguendo WindowsAppRuntimeInstall.exe. In caso contrario, si verifica un errore NOT_FOUND a causa di Visual Studio che non distribuisce il framework x64, il quale in genere si verifica tramite la distribuzione dello Store o il trasferimento locale.

Ciclo di vita dell'app

La maggior parte delle funzionalità del ciclo di vita delle app esiste già nella piattaforma UWP ed è stata inserita in Windows App SDK per l'uso da parte dei tipi di app desktop, in particolare le app console non incluse nel pacchetto, le app Win32, le app Windows Form e le app WPF. L'implementazione Windows app SDK di queste funzionalità non può essere usata nelle app UWP, perché esistono funzionalità equivalenti nella piattaforma UWP stessa.

Le app non UWP possono anche essere inserite in pacchetti MSIX. Anche se queste app possono usare alcune delle funzionalità del ciclo di vita delle app Windows app SDK, devono usare l'approccio manifesto in cui è disponibile. Ad esempio, non possono usare le API Windows App SDK RegisterForXXXActivation e devono invece registrarsi per l'attivazione avanzata tramite il manifesto.

Tutti i vincoli per le app in pacchetto si applicano anche alle app WinUI 3, incluse in un pacchetto, e ci sono considerazioni aggiuntive, come descritto di seguito.

Considerazioni importanti:

  • Attivazione avanzata: GetActivatedEventArgs

  • Registrazione/Annullamento della registrazione per l'attivazione avanzata

  • Creazione di istanze singole/multiple

    • App non incluse nel pacchetto: completamente utilizzabile.
    • App non incluse nel pacchetto: completamente utilizzabile.
    • app WinUI 3: se un'app vuole rilevare altre istanze e reindirizzare un'attivazione, deve farlo il prima possibile e prima di inizializzare qualsiasi finestra e così via. A tale scopo, l'app deve definire DISABLE_XAML_GENERATED_MAIN e scrivere un main personalizzato (C#) o WinMain (C++) in cui può eseguire il rilevamento e il reindirizzamento.
    • RedirectActivationToAsync è una chiamata asincrona e non è consigliabile attendere una chiamata asincrona se l'app è in esecuzione in una STA. Per Windows Form e app WinUI 3 C#, si può dichiarare Main come asincrono, se necessario. Per le app WinUI 3 e C# WPF di C++ non è possibile dichiarare Main come asincrona, quindi è necessario spostare la chiamata di reindirizzamento a un altro thread per assicurarsi di non bloccare la STA.
    • Per altre informazioni, vedere Creazione di istanze dell'app con l'API ciclo di vita dell'app.

  • Notifiche di alimentazione/stato

Problema noto:

Le associazioni tipo di file codificano in modo non corretto %1 come %251 quando si imposta il modello della riga di comando del gestore verbo, che arresta in modo anomalo le app Win32 non incluse nel pacchetto. È possibile modificare manualmente il valore del Registro di sistema in modo che sia %1 come soluzione alternativa parziale. Se il percorso del file di destinazione contiene uno spazio, l'operazione avrà comunque esito negativo e non è disponibile alcuna soluzione alternativa per tale scenario.

Altre limitazioni e problemi noti:

  • La versione 1.0 Preview 1 e Preview 2 contiene un bug critico. Se è già stata installata una di queste anteprime, consultare la sezione Come risolvere il problema. È consigliabile usare invece la versione 1.0 Preview 3 .

  • Questa versione presenta i modelli App vuota, In pacchetto (WinUI 3 in Desktop) per i progetti C# e C++. Questi modelli consentono di compilare l'app in un pacchetto MSIX senza l'uso di un progetto di creazione di pacchetti separato. Questi modelli presentano alcuni problemi noti in questa versione:

    • Modello C# per Visual Studio 2019. Si verifica l'errore quando si tenta di compilare il progetto: "Il progetto non sa come eseguire il nome progetto del profilo". Per risolvere questo problema, installare l'estensione Strumenti di creazione pacchetti MSIX a progetto singolo.

    • Modello C# per Visual Studio 2019 e Visual Studio 2022. Quando si tenta l'esecuzione o si tenta di eseguire il debug del progetto nel computer di sviluppo, si verifica l'errore seguente: "Il progetto deve essere distribuito prima di poter eseguire il debug. Abilitare Distribuisci in Configuration Manager." Per risolvere questo problema, abilitare la distribuzione per il progetto in Configuration Manager. Per istruzioni dettagliate, consultare la sezione Creazione del primo progetto WinUI 3 (Windows App SDK).

    • Modello C++ per Visual Studio 2019 e Visual Studio 2022. In questa versione, questi progetti sono limitati a chiamare il subset di API Win32 che possono essere chiamate dalle app UWP. Il modello App vuota, in pacchetto con WAP (WinUI 3 in Desktop) non è interessato da questo problema.

    • Modello C++ per Visual Studio 2022 versione 17,0 fino alla Preview 4. Si verifica il seguente errore la prima volta che si tenta di eseguire il progetto: "Si sono verificati errori di distribuzione". Per risolvere questo problema, eseguire o distribuire il progetto una seconda volta. Questo problema verrà risolto in Visual Studio 2022 versione 17.0 Preview 5.

  • API notifiche push (spazio dei nomi Microsoft.Windows.PushNotifications) inclusa erroneamente nella versione 1.0 Preview 2. Questa è ancora una funzionalità sperimentale e per usarla è necessario installare invece la versione sperimentale 1.0. Questa funzionalità verrà rimossa dalla prossima versione 1.0.

  • L'API del ciclo di vita dell'app (spazio dei nomi Microsoft.Windows.AppLifecycle) include erroneamente l'attributo Experimental nella versione 1.0 Preview 2. L'attributo Experimental verrà rimosso da questa API nella versione successiva.

  • Nessun supporto per qualsiasi configurazione di compilazione cpu: quando si aggiunge Windows App SDK a un'applicazione o a un componente .NET esistente che supporta Qualsiasi CPU, è necessario specificare l'architettura desiderata: x86 o x64 arm64.

  • +I progetti C# che usano la versione 1.0 Preview 2 devono usare il seguente .NET SDK: .NET 6 SDK o versione successiva (vedere Download .NET e .NET 5 raggiungeranno la fine del supporto il 10 maggio 2022).

  • Un'alternativa a DispatcherQueue.TryEnqueue (per riprendere l'esecuzione nel thread della coda del dispatcher) consiste nell'usare la funzione helper resume_foreground nella Libreria di implementazione di Windows (WIL):

    1. Per prima cosa, aggiungere un riferimento al progetto al pacchetto NuGet Microsoft.Windows.ImplementationLibrary.
    2. Aggiungere #include <wil/cppwinrt_helpers.h> al proprio pch.h.
    3. Aggiungere #include <winrt/Microsoft.UI.Dispatching.h> al proprio pch.h.
    4. Ora co_await wil::resume_foreground(your_dispatcherqueue);.

Versione 1.0 Anteprima (1.0.0-preview1)

Importante

La versione 1.0 Preview 1 e Preview 2 contiene un bug critico. Se è già stata installata una di queste anteprime, consultare la sezione Come risolvere il problema. È consigliabile usare invece la versione 1.0 Preview 3 .

Questa è la prima versione del canale di anteprima per la versione 1.0. Supporta tutte le funzionalità del canale di anteprima.

Nelle sezioni seguenti vengono descritte le funzionalità nuove e aggiornate, le limitazioni e i problemi noti di questa versione.

WinUI 3 (1.0.0-preview1)

Questa versione di WinUI 3 è incentrata sulla compilazione verso la versione 1.0 con correzioni di bug.

  • Nuove funzionalità Nessuna nuova funzionalità nell'anteprima 1.
  • Problemi corretti: per l'elenco completo dei problemi risolti in questa versione, vedere il nostro repository GitHub.

Per altre informazioni o per iniziare a sviluppare con WinUI 3, vedere:

Windowing (1.0.0-preview1)

Questa versione porta l'API Windowing introdotta in Experimental 1 a uno stato di anteprima. In questa versione non sono presenti nuove aree principali in quanto sono incentrate su correzioni di bug, stabilità e modifiche alla firma dell'API. Le modifiche e le aggiunte degne di nota sono indicate di seguito.

Nuove funzionalità:

  • DisplayAreaWatcher è stato aggiunto alle API windowing. Questa funzionalità consente a uno sviluppatore di osservare le modifiche nella topologia di visualizzazione ed enumerare le DisplayAreas attualmente definite nel sistema.
  • AppWindow supporta ora l'impostazione dell'icona della finestra tramite il metodo SetIcon mentre AppWindowTitleBar supporta ora la selezione della selezione della visualizzazione/nascondere l'icona della finestra insieme al menu di sistema tramite la proprietà IconShowOptions .

Limitazioni importanti:

  • Questa versione di AppWindow è attualmente disponibile solo per le app Win32 (incluse nel pacchetto e non incluse nel pacchetto).
  • Al momento Windows App SDK non fornisce metodi per collegare il contenuto del framework dell'interfaccia utente a un AppWindow; è possibile usare solo i metodi di accesso di interoperabilità.
  • La personalizzazione della barra del titolo della finestra funziona solo in Windows 11. Usare il metodo IsCustomizationSupported per verificare il supporto delle funzionalità di personalizzazione della barra del titolo. L'intento è di portare questa funzionalità a un livello inferiore.

Per maggiori informazioni, consultare la sezione Gestione delle app Windows (Windows App SDK).

Input (1.0.0-preview1)

Questa versione introduce alcune nuove funzionalità nell'API input. Le modifiche e le aggiunte degne di nota sono indicate di seguito.

Nuove funzionalità e aggiornamenti

  • PointerPredictor offre applicazioni sensibili alla latenza di input, come le applicazioni di inchiostrazione, la possibilità di prevedere le posizioni dei punti di input fino a 15 ms in futuro, per ottenere una latenza migliore e un'animazione fluida.
  • PenDeviceInterop consente di acquisire un riferimento a Windows.Devices.Input.PenDevice usando il metodo FromPointerPoint .
  • InputCursor fornisce una distinzione esplicita tra i tipi di cursore di sistema predefiniti e i tipi di cursore personalizzati rimuovendo il tipo "Personalizzato" già disponibile in CoreCursor, e suddividendo l'oggetto CoreCursor in oggetti separati.
  • Aggiornamenti a API InputCursor.
  • GestureRecognizer è stato spostato da sperimentale a Microsoft.UI.Input.
  • PointerPoint è stato spostato da experimental a Microsoft.UI.Input.
  • Input tramite mouse, tocco e penna completamente supportato per il trascinamento della selezione di WinUI 3.

Limitazioni importanti:

  • Questa versione delle API di input presenta problemi noti con Windows versione 1809.
  • MRT Core non è ancora supportato da alcun sottotipo di InputCursor.
  • L'uso diretto dell'API dell'SDK della piattaforma Windows.UI.Core.CoreDragOperation non funzionerà con le applicazioni WinUI 3.
  • Le proprietà PointerPoint RawPosition e ContactRectRaw sono state rimosse perché hanno fatto riferimento a valori non stimati, che erano uguali ai valori normali nel sistema operativo. Utilizzare invece Position e ContactRect. La stima del puntatore viene ora gestita con l'oggetto API Microsoft.UI.Input.PointerPredictor .

MRT Core (1.0.0-preview1)

A partire dalla versione 1.0 Preview 1, le API MRT Core sono state spostate dallo spazio dei nomi Microsoft.ApplicationModel.Resources allo spazio dei nomi Microsoft.Windows.ApplicationModel.Resources .

Altre limitazioni e problemi noti:

  • La versione 1.0 Preview 1 e Preview 2 contiene un bug critico. Se è già stata installata una di queste anteprime, consultare la sezione Come risolvere il problema. È consigliabile usare invece la versione 1.0 Preview 3 .

  • Per impostazione predefinita, i progetti creati usando App vuota, inclusa nel pacchetto con WAP (WinUI 3 in Desktop) per C++ riscontrano il seguente errore di compilazione: fatal error C1083: Cannot open include file: 'winrt/microsoft.ui.dispatching.co_await.h': No such file or directory. Per risolvere questo problema, rimuovere la riga di codice seguente dal file pch.h. Questo problema verrà risolto nella prossima versione.

    #include <winrt/microsoft.ui.dispatching.co_await.h>

  • Un'alternativa a DispatcherQueue.TryEnqueue (per riprendere l'esecuzione nel thread della coda del dispatcher) consiste nell'usare la funzione helper resume_foreground nella Libreria di implementazione di Windows (WIL):

    1. Per prima cosa, aggiungere un riferimento al progetto al pacchetto NuGet Microsoft.Windows.ImplementationLibrary.
    2. Aggiungere #include <wil/cppwinrt_helpers.h> al proprio pch.h.
    3. Aggiungere #include <winrt/Microsoft.UI.Dispatching.h> al proprio pch.h.
    4. Ora co_await wil::resume_foreground(your_dispatcherqueue);.

  • Nessun supporto per la configurazione di compilazione Qualsiasi CPU: Windows App SDK viene scritto nel codice nativo e pertanto non supporta le configurazione di compilazione Qualsiasi CPU. I modelli WinUI 3 in Visual Studio consentono solo compilazioni specifiche per l'architettura. Quando si aggiunge Windows App SDK a un'applicazione o a un componente .NET esistente che supporta Qualsiasi CPU, è necessario specificare l'architettura desiderata: x86o x64 arm64.

  • Le app .NET devono avere come destinazione la build 18362 o successive: il TFM deve essere impostato su net6.0-windows10.0.18362 o successive e la <TargetPlatformVersion> del progetto di creazione del pacchetto su 18362 o successive. Per altre informazioni, vedere il problema noto su GitHub.

  • +I progetti C# che usano la versione 1.0 Preview 1 devono usare il seguente .NET SDK: .NET 6 SDK o versione successiva (vedere Download .NET e .NET 5 raggiungeranno la fine del supporto il 10 maggio 2022).

  • App senza pacchetti non supportate in Windows 10 versione 1809: questa operazione deve essere risolta nella versione successiva.