Note sulla versione di Windows App SDK 1.0

È possibile scegliere tra i canali Stabile, Anteprima e Sperimentale a seconda delle esigenze di sviluppo, dalle build di produzione affidabili all'accesso anticipato alle funzionalità future. Altre informazioni sui canali di rilascio.

Per il runtime e l'MSIX aggiornati, vedere anche Download per il Windows App SDK.

Versione 1.0.4

Correzioni
  • È stato risolto un problema che causava le AppBars, quando utilizzati come Page.TopAppBar o Page.BottomAppBar, a non venire visualizzate sullo schermo.
  • È stato risolto un problema per cui le app con un nome di pacchetto di 12 caratteri o meno che usano un controllo WinUI da MUXControls.dll si bloccano immediatamente. Per altre informazioni, vedere il problema 6360 su GitHub.
  • Risolti i problemi di input tattile che causavano difficoltà con le scorciatoie da tastiera e altri scenari. Per altre informazioni, vedere il problema 6291 su GitHub.
  • È stato risolto un problema che causava il fallimento della distribuzione delle app in pacchetto con MSIX o distribuite come autonome.
  • È stato risolto un problema che causava un arresto anomalo delle app durante un'operazione di trascinamento e rilascio. Per altre informazioni, vedere il problema 7002 su GitHub.

Versione 1.0.3

Correzioni
  • È stato risolto un problema che causava l'arresto anomalo delle app C# con WebView2 all'avvio quando il runtime C/C++ (CRT) non è installato.
  • Risolti i problemi di input tattile che causavano difficoltà con le scorciatoie da tastiera e altri scenari. Per altre informazioni, vedere il problema 6291 su GitHub.

Nota: in genere non si aggiungono funzionalità in una versione di manutenzione, ma la correzione WebView2 di questa versione richiede l'aggiornamento alla versione più recente di WebView2 SDK (da 1020.46 a 1185.39). Per ulteriori informazioni su WebView2 1.0.1185.39, vedere Note sulla versione per il WebView2 SDK e, per ulteriori informazioni sul runtime WebView2, vedere Distribuire l'app e il runtime WebView2.

Versione 1.0.2

Si tratta di una versione di manutenzione di Windows App SDK che include correzioni di bug critiche per la versione 1.0.

Correzioni
  • Risolto il problema del ciclo di layout che causava l'arresto anomalo di un'app durante lo scorrimento fino alla fine di un ListView. Per altre informazioni, vedere il problema 6218 su GitHub.
  • È stato risolto un problema che causava l'arresto anomalo delle app C# all'avvio quando il runtime C/C++ (CRT) non è installato. Tuttavia, CRT è ancora necessario per le app C# che usano WebView2. Per altre informazioni, vedere il problema 2117 su GitHub.
  • È stato risolto un problema per cui le applicazioni con MSIX a progetto singolo non generavano un file con estensione appinstaller. Per altre informazioni, vedere il problema 1821 su GitHub.
  • È stato risolto un problema per cui le applicazioni WinUI non supportavano .NET 6 dotnet build.

Versione 1.0.1

Si tratta di una versione di manutenzione di Windows App SDK che include correzioni di bug critiche e supporto per più finestre per la versione 1.0.

Correzioni
  • È stato risolto un problema che causava la mancata compilazione di MddBootstrapAutoinitializer con implicitUsing abilitati. Per altre informazioni, vedere il problema 1686 su GitHub.
  • È stato risolto un problema che causava la perdita inattesa del focus in WebView2, causando problemi di input e selezione. Per altre informazioni, vedere il problema 5615 & problema 5570 su GitHub.
  • È stato risolto un problema che causava l'impossibilità di fare clic sulla barra degli strumenti in-app in Visual Studio quando si usa una barra del titolo personalizzata in un'app WinUI.
  • È stato risolto un problema che causava la mancata visualizzazione del layout di snap quando si usa una barra del titolo personalizzata in un'app WinUI. Per altre informazioni, vedere il problema 6333 & problema 6246 su GitHub.
  • È stato risolto un problema che causava un'eccezione durante l'impostazione della proprietà Window.ExtendsContentIntoTitleBar quando window.SetTitlebar è stato chiamato con un UIElement ancora in fase di caricamento.
  • È stato risolto un problema per cui le app MSIX a progetto singolo non supportavano dotnet build.
  • È stato risolto un problema che impediva l'installazione di app non confezionate dopo l'installazione di un'app confezionata. Per altre informazioni, vedere il problema 1871 su GitHub.
  • Correzione del problema di riduzione delle prestazioni durante le operazioni di trascinamento del mouse.
  • Correzione dell'arresto anomalo durante la chiamata a GetWindowIdFromWindow() nelle app non impacchettate. Per altre informazioni, vedere discussione 1891 su GitHub.

Le limitazioni e i problemi noti per la versione 1.0 si applicano anche alla versione 1.0.1.

Inoltre, per le app con barre del titolo personalizzate, sono state apportate modifiche in questo rilascio (e sono stati risolti numerosi problemi) che includono correzioni alla finestra trasparente usata per le operazioni di trascinamento della selezione. La raccomandazione consiste nell'usare i valori e i comportamenti predefiniti (dare loro un tentativo!). Se la barra del titolo usa i margini in modo che i pulsanti didascalia predefiniti siano interattivi, è consigliabile visualizzare l'area di trascinamento impostando lo sfondo della barra del titolo su rosso e quindi modificando i margini per estendere l'area di trascinamento ai controlli didascalia.

Nuove funzionalità

Abbiamo stabilizzato e abilitato la creazione di più finestre nello stesso thread nelle applicazioni WinUI. Per altre informazioni, vedere il problema 5918 .

Versione 1.0

WinUI 3

WinUI 3 è il framework UX (Native User Experience) per Windows App SDK. In questa versione sono state aggiunte più nuove funzionalità di Windows App SDK 0.8 e problemi stabilizzati dalle versioni di anteprima 1.0.

Nuove funzionalità e aggiornamenti:

  • Sono stati aggiunti nuovi controlli (PipsPager, Expander, BreadcrumbBar) e sono stati aggiornati i controlli esistenti per riflettere gli stili di Windows più recenti di WinUI per UWP 2.6.
  • La pacchettizzazione MSIX per progetto singolo è supportata su WinUI creando una nuova applicazione usando il modello 'App vuota, in pacchetto...'.
  • È ora supportata la distribuzione di app WinUI non in pacchetto nelle versioni di Windows 1809 e successive. Per altre informazioni, vedere Creare il primo progetto WinUI 3 (Windows App SDK).
  • I progetti WinUI 3 ora possono impostare la versione di destinazione su Windows 10, versione 1809. In precedenza, potevano essere impostati solo a partire dalla versione 1903.
  • Nella barra degli strumenti in-app, Hot Reload e Albero Visuale Live per le applicazioni impacchettate WinUI sono supportati in Visual Studio 2022 Preview 5 e GA.

Limitazioni importanti:

  • Problemi noti per le applicazioni WinUI in pacchetto e non in pacchetto:

    • Errore di runtime nelle app C++ o C# che fanno riferimento a un componente Windows Runtime C++:

      • Per risolvere il problema, aggiungere il seguente target alla fine del .vcxproj del componente Windows Runtime.
      <Target Name="GetPriIndexName">
<PropertyGroup>
    <!-- Winmd library targets use the default root namespace of the project for the App package name -->
    <PriIndexName Condition="'$(RootNamespace)' != ''">$(RootNamespace)</PriIndexName>
    <!-- If RootNamespace is empty fall back to TargetName -->
    <PriIndexName Condition="$(PriIndexName) == ''">$(TargetName)</PriIndexName>
</PropertyGroup>
</Target>
      • L'errore previsto sarà simile all'errore di origine winRT - 0x80004005 : 'Impossibile individuare la risorsa da 'ms-appx:///BlankPage.xaml'.'.

  • Problemi noti per le applicazioni WinUI con MSIX a progetto singolo (app vuota, modello in pacchetto):

    • Voce di menu Pacchetto & Pubblicazione mancante fino al riavvio di Visual Studio: Quando si crea una nuova app con MSIX a progetto unico sia in Visual Studio 2019 che in Visual Studio 2022 usando il modello di progetto App vuota, con pacchetto (WinUI 3 in Desktop), il comando per pubblicare il progetto non viene visualizzato nel menu fino a quando non si chiude e si riapra Visual Studio.
    • Un'app C# con MSIX a progetto singolo non verrà compilata senza il componente facoltativo "C++ (v14x) Universal Windows Platform Tools". Per altre informazioni, vedere Installare gli strumenti per Windows App SDK .
    • Potenziale errore di run-time in un'app con MSIX a progetto singolo che utilizza i tipi definiti in un componente Windows Runtime a cui si fa riferimento: Per risolvere il problema, aggiungere manualmente voci di classe attivabili al appxmanifest.xml.
      • L'errore previsto nelle applicazioni C# è "COMException: Classe non registrata (0x80040154 (REGDB_E_CLASSNOTREG)).
      • L'errore previsto nelle applicazioni C++/WinRT è "winrt::hresult_class_not_registered".

  • Problemi noti per le app WinUI non in pacchetto (app non in pacchetto):

  • Problemi noti per la creazione di pacchetti e la distribuzione di applicazioni WinUI:

    • Il Package comando non è supportato nelle app WinUI con MSIX a progetto singolo (app vuota, modello in pacchetto). Usare invece il Package & Publish comando per creare un pacchetto MSIX.
    • Per creare un pacchetto NuGet da una libreria di classi C# con il Pack comando , assicurarsi che l'elemento attivo Configuration sia Release.
    • Il Pack comando non è supportato nei componenti Windows Runtime C++ per creare un pacchetto NuGet.

Per altre info o per iniziare a sviluppare con WinUI, vedi:

Windowing

Windows App SDK fornisce una classe AppWindow che evolve la precedente classe windows.UI.WindowManagement.AppWindow preview e la rende disponibile per tutte le app di Windows, tra cui Win32, WPF e WinForms.

Nuove funzionalità:

  • AppWindow è un'API di windows di alto livello che consente scenari di windowing facili da usare che si integrano bene con l'esperienza utente di Windows e con altre app. Rappresenta un'astrazione generale di un contenitore gestito dal sistema del contenuto di un'app. Si tratta del contenitore in cui è ospitato il contenuto e rappresenta l'entità con cui gli utenti interagiscono quando ridimensionano e spostano l'app sullo schermo. Per gli sviluppatori che hanno familiarità con Win32, AppWindow può essere vista come un'astrazione di alto livello di HWND.
  • DisplayArea rappresenta un'astrazione generale di un HMONITOR, segue gli stessi principi di AppWindow.
  • DisplayAreaWatcher consente a uno sviluppatore di osservare le modifiche nella topologia di visualizzazione ed enumerare DisplayAreas attualmente definito nel sistema.

Per altre info, vedi Gestire le finestre delle app (Windows App SDK).

Input

Queste sono le API di input che supportano WinUI e forniscono una superficie API di livello inferiore per gli sviluppatori per ottenere interazioni di input più avanzate.

Nuove funzionalità:

  • API puntatore: PointerPoint, PointerPointProperties e PointerEventArgs per supportare il recupero delle informazioni sugli eventi del puntatore con le API di input XAML.
  • API InputPointerSource: rappresenta un oggetto registrato per segnalare l'input del puntatore e fornisce la gestione degli eventi di input e cursore del puntatore per l'API SwapChainPanel di XAML.
  • API cursore: consente agli sviluppatori di modificare la bitmap del cursore.
  • API GestureRecognizer: consente agli sviluppatori di riconoscere determinati movimenti, ad esempio trascinamento, tenere premuto e fare clic quando vengono specificate informazioni sul puntatore.

Limitazioni importanti:

  • Tutte le funzioni factory statiche 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 esistente. Per i punti intermedi, è possibile utilizzare le funzioni membro PointerEventArgsGetIntermediatePoints e GetTransformedIntermediatePoints.
  • L'uso diretto dell'API dell'SDK della piattaforma Windows.UI.Core.CoreDragOperation non funzionerà con le applicazioni WinUI.
  • Le proprietà PointerPointRawPosition e ContactRectRaw sono state rimosse perché hanno fatto riferimento a valori non stimati, che erano uguali ai valori normali nel sistema operativo. Usare Position e ContactRect invece. La stima del puntatore viene ora gestita con l'oggetto API Microsoft.UI.Input.PointerPredictor .
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 di tipi di app desktop, in particolare app console non in pacchetto, app Win32, app Windows Form e app WPF. L'implementazione di 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. Sebbene queste app possano usare alcune delle funzionalità del ciclo di vita delle app di Windows App SDK, devono usare l'approccio manifesto in cui è disponibile. Ad esempio, non possono usare le API RegisterForXXXActivation di Windows App SDK 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, 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

  • Istanze Singole/Multi-istanza

    • App non in pacchetto: completamente utilizzabile.
    • App in pacchetto: completamente utilizzabile.
    • App WinUI: 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 dovresti attendere una chiamata asincrona se l'app è in esecuzione in un STA. Per le app Windows Form e WinUI C#, è possibile dichiarare Main come asincrona, se necessario. Per le app C++ WinUI e C# WPF, non è possibile dichiarare Main come asincrono, quindi è necessario spostare la chiamata di reindirizzamento a un altro thread per assicurarsi di non bloccare la STA.
    • Per ulteriori informazioni, vedi Instanziazione dell'app con l'API del ciclo di vita dell'app.

  • Notifiche di potenza/stato

Problema noto:

  • Le associazioni tipo di file codificano erroneamente %1 diventando %251 quando si imposta il modello della riga di comando del gestore dei verbi, il che provoca l'arresto anomalo delle app Win32 non impacchettate. È 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.
  • Questi bug di singola/multi istanza verranno corretti in una imminente patch di manutenzione:
    • Il reindirizzamento appInstance non funziona quando viene compilato per x86
    • Il processo di registrazione, annullamento della registrazione e ri-registrazione di una chiave causano l'arresto anomalo dell'app.
DWriteCore

DWriteCore è l'implementazione nello SDK per app di Windows di DirectWrite, che è l'API di DirectX per il rendering di testo di alta qualità, i caratteri outline indipendenti dalla risoluzione e il supporto completo per il testo e il layout Unicode. DWriteCore è una forma di DirectWrite eseguita nelle versioni di Windows fino a Windows 10, versione 1809 (10.0; Build 17763) e apre la porta per l'uso multipiattaforma.

Funzionalità:

DWriteCore contiene tutte le funzionalità di DirectWrite, con alcune eccezioni.

Limitazioni importanti:

  • DWriteCore non contiene le seguenti funzionalità di DirectWrite:
    • Tipi di carattere per sessione
    • Tipi di carattere definiti dall'utente finale (EUDC)
    • API di streaming dei tipi di carattere
  • Il supporto dell'API di rendering di basso livello è parziale.
  • DWriteCore non interagisce con Direct2D, ma è possibile usare IDWriteGlyphRunAnalysis e IDWriteBitmapRenderTarget.

Per altre informazioni, vedere Panoramica di DWriteCore.

MRT Core

MRT Core è una versione semplificata del sistema di gestione delle risorse di Windows moderno distribuito come parte di Windows App SDK.

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, ricompila l'app. Per altre informazioni, vedi il problema 1503 .

  • Nei progetti .NET, quando un file di risorse viene aggiunto al progetto usando l'interfaccia utente di Visual Studio, i file potrebbero non essere indicizzati per impostazione predefinita. Per altre informazioni, vedi il problema 1786 . Per risolvere questo problema, rimuovere le voci seguenti nel file CSPROJ:

    <ItemGroup>
    <Content Remove="<image file name>" />
</ItemGroup>
<ItemGroup>
    <PRIResource Remove="<resw file name>" />
</ItemGroup>

  • Per le app WinUI C++ non in pacchetto, l'URI della risorsa non viene compilato correttamente. Per risolvere questo problema, aggiungere quanto segue in vcxproj:

    <!-- Add the following after <Import Project="$(VCTargetsPath)\Microsoft.Cpp.props" /> -->

<PropertyGroup>
    <AppxPriInitialPath></AppxPriInitialPath>   
</PropertyGroup>

Per altre informazioni, vedere Gestire le risorse con MRT Core.

Distribuzione

Nuove funzionalità e aggiornamenti:

Limitazioni importanti:

  • Il wrapper .NET per l'API del programma di avvio automatico è destinato solo alle applicazioni .NET non in pacchetto per semplificare l'accesso a Windows App SDK.
  • Solo le app in pacchetto MSIX che sono attendibili o hanno la 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 applicazioni pacchettizzate con attendibilità parziale sarà introdotto nelle versioni future.
  • Quando F5 testa un'app x86 che usa il metodo DeploymentManager.Initialize in un sistema x64, verificare che il framework x64 sia installato prima eseguendo il WindowsAppRuntimeInstall.exe. In caso contrario, si verificherà un errore NOT_FOUND perché Visual Studio non distribuisce il framework x64, che normalmente avviene tramite distribuzione tramite Store o sideloading.
Altre limitazioni e problemi noti

  • 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: x86o x64arm64.

  • Aggiornamento da .NET 5 a .NET 6: quando si esegue l'aggiornamento nell'interfaccia utente di Visual Studio, è possibile che si verifichino errori di compilazione. Come soluzione alternativa, aggiornare manualmente il file di TargetFrameworkPackage progetto con quanto segue:

      <TargetFramework>net8.0-windows10.0.19041.0</TargetFramework>

  • 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) Universal Windows Platform Tools .

  • Il linguaggio VSIX successivo non viene installato in Visual Studio 2019 quando vengono installate più versioni di Visual Studio 2019. Se sono installate più versioni di Visual Studio 2019 (ad esempio Release e Preview) e quindi si installa Windows App SDK VSIX sia per C++ che per C#, la seconda installazione avrà esito negativo. Per risolvere il problema, disinstallare MSIX Packaging Tools a progetto singolo per Visual Studio 2019 dopo il primo linguaggio VSIX. Visualizzare questo feedback per altre informazioni su questo problema.

  • 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):An alternative to DispatcherQueue.TryEnqueue (for resuming execution on the dispatcher queue thread) is to use the resume_foreground helper function in the Windows Implementation Library (WIL):

    1. Aggiungere un riferimento al progetto al pacchetto NuGet Microsoft.Windows.ImplementationLibrary .
    2. Aggiungere #include <wil/cppwinrt_helpers.h> all'oggetto pch.h.
    3. Aggiungere #include <winrt/Microsoft.UI.Dispatching.h> all'oggetto pch.h.
    4. Ora co_await wil::resume_foreground(your_dispatcherqueue);.

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

Annotazioni

Se sono già installate le estensioni di Visual Studio (VSIX) di Windows App SDK, disinstallarle prima di installare una nuova versione. Per istruzioni, vedere Gestire le 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, vedi Download più recenti di Windows App SDK. Se non è già stato fatto, iniziare configurando l'ambiente di sviluppo seguendo la procedura descritta in Installare gli strumenti per Windows App SDK.

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

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

Le sezioni seguenti descrivono funzionalità, limitazioni e problemi noti nuovi e aggiornati per la versione 1.0 Preview 3.

WinUI 3 (1.0.0-preview3)

Ora è supportata la distribuzione di app WinUI senza pacchetti MSIX. Vedi Creare il primo progetto WinUI 3 (Windows App SDK) per configurare l'applicazione WinUI per supportare la distribuzione non in pacchetto.

Limitazioni importanti:

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

Per altre info o per iniziare a sviluppare con WinUI 3, vedi:

Altre limitazioni e problemi noti:

  • Le app non in 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) Universal Windows Platform Tools .

  • Questa versione introduce i modelli di progetto Blank App, Packaged (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 di creazione di pacchetti separato (vedi Creare 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, In pacchetto (WinUI 3 in Desktop), il comando per pubblicare il progetto non viene visualizzato nel menu finché non si chiude e si riapri Visual Studio.

    • Errore durante l'aggiunta di riferimenti a progetti di libreria statica/dinamica C++ alle app C++ usando la creazione di pacchetti MSIX a progetto singolo. Visual Studio visualizza un errore che indica che il progetto non può essere aggiunto come riferimento perché 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 con l'errore che il sistema non riesce a trovare il percorso specificato.

    • Modello C# o C++ per Visual Studio 2019. Quando si tenta di compilare il progetto, viene visualizzato l'errore "Il progetto non sa come eseguire il nome del progetto profilo". Per risolvere questo problema, installare l'estensione MSIX Packaging Tools a progetto singolo.

    • Modello C# per Visual Studio 2019 e Visual Studio 2022. In Visual Studio quando si avvia il debug o si avvia senza eseguire 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 di eseguire o 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 Deploy in Configuration Manager." Per risolvere questo problema, abilitare la distribuzione per il progetto in Configuration Manager. Per istruzioni dettagliate, vedere creare il primo progetto WinUI 3 (Windows App SDK).

    • Il modello C++ per Visual Studio 2022 versione 17.0 è disponibile 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: x86o x64arm64.

  • I progetti C# che usano la versione 1.0 Preview 3 devono usare .NET SDK seguente: .NET 6 SDK o versione successiva (vedere Scaricare .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):An alternative to DispatcherQueue.TryEnqueue (for resuming execution on the dispatcher queue thread) is to use the resume_foreground helper function in the Windows Implementation Library (WIL):

    1. Aggiungere un riferimento al progetto al pacchetto NuGet Microsoft.Windows.ImplementationLibrary .
    2. Aggiungere #include <wil/cppwinrt_helpers.h> all'oggetto pch.h.
    3. Aggiungere #include <winrt/Microsoft.UI.Dispatching.h> all'oggetto 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 Preview 2 di Windows App SDK include un meccanismo per pulire tutte le modifiche delle variabili di ambiente apportate da un'app in 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 di sistema.

L'anteprima 1 e l'anteprima 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 problema di danneggiamento delle variabili di ambiente PATH.

Dettagli

La voce PATH di sistema 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 deve essere di tipo REG_EXPAND_SZ, ma il bug lo modifica in REG_SZ. Ciò rende inutilizzabile la variabile di ambiente PATH di sistema se contiene il carattere %di espansione della variabile .

Versioni interessate

Mitigazione

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 lo script di Windows PowerShell seguente (PowerShell Core non funzionerà). Eseguilo 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 di 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 lo script di Windows PowerShell seguente (PowerShell Core non funzionerà). Eseguilo 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 prossima versione 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.

Versione 1.0 Preview 2 (1.0.0-preview2)

Importante

La versione 1.0 Preview 1 e Preview 2 contengono un bug critico. Se è già stata installata una di queste anteprime, vedere come risolvere il problema.

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

Le sezioni seguenti descrivono funzionalità, limitazioni e problemi noti nuovi e aggiornati per 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 per UWP 2.6.
  • Il supporto per MSIX a progetto singolo è garantito.
  • Il pacchetto WinUI 3 può ora essere destinato alla build 17763 e versioni successive. Per altre informazioni, vedere il problema n. 921 .
  • La barra degli strumenti in-app è supportata. Tuttavia, la barra degli strumenti in-app e il supporto di Ricaricamento rapido/Albero visuale attivo esistente 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 info o per iniziare a sviluppare con WinUI 3, vedi:

Gestione delle Finestre (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 sperimentali o 1.0 Preview 1, aspettarsi alcune modifiche al codice.

Nuovi aggiornamenti:

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

Limitazioni importanti:

  • Windows App SDK attualmente non fornisce metodi per collegare il contenuto del framework dell'interfaccia utente a un'AppWindow; è possibile usare i metodi di accesso di interoperabilità HWND.
  • 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. Questa funzionalità è di livello inferiore.

Per altre info, vedi Gestire le finestre delle app (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 factory statiche 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 esistente. Per i punti intermedi, è possibile utilizzare le funzioni membro PointerEventArgsGetIntermediatePoints e GetTransformedIntermediatePoints. Per altri 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, vedi 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, ricompila l'app. Per altre informazioni, vedi 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 ulteriori informazioni, vedi la questione 1504.

Distribuzione per le applicazioni non in pacchetto

nuove funzionalità:

  • Windows App SDK 1.0 Preview 2 introduce un wrapper .NET per l'API del bootstrapper (vedere Usare il runtime di Windows App SDK per le app confezionate con percorso esterno o senza pacchetti). L'API del programma di avvio automatico è un set di funzioni C/C++ native che le app non in 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 chiamare 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 in pacchetto dovranno eseguire questo passaggio aggiuntivo per ottenere tali pacchetti installati. Per altre info sul funzionamento dell'API di distribuzione, vedi Guida alla distribuzione di Windows App SDK per le app in pacchetto dipendenti dal framework.

Limitazioni importanti:

  • Il wrapper .NET per l'API del programma di avvio automatico è destinato solo all'uso da applicazioni .NET non in pacchetto per semplificare l'accesso a Windows App SDK.
  • Solo le app in pacchetto MSIX che sono attendibili o hanno la 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 applicazioni pacchettizzate con attendibilità parziale sarà introdotto nelle versioni future.
  • Quando F5 testa un'app x86 che usa il metodo DeploymentManager.Initialize in un sistema x64, verificare che il framework x64 sia installato prima eseguendo il WindowsAppRuntimeInstall.exe. In caso contrario, si verificherà un errore NOT_FOUND perché Visual Studio non distribuisce il framework x64, che normalmente avviene tramite distribuzione tramite Store o sideloading.

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 di tipi di app desktop, in particolare app console non in pacchetto, app Win32, app Windows Form e app WPF. L'implementazione di 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. Sebbene queste app possano usare alcune delle funzionalità del ciclo di vita delle app di Windows App SDK, devono usare l'approccio manifesto in cui è disponibile. Ad esempio, non possono usare le API RegisterForXXXActivation di Windows App SDK 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 in pacchetto; e ci sono altre considerazioni, come descritto di seguito.

Considerazioni importanti:

  • Attivazione avanzata: GetActivatedEventArgs

  • Registrazione/Annullamento della registrazione per l'attivazione avanzata

  • Istanze Singole/Multi-istanza

    • App non in pacchetto: completamente utilizzabile.
    • App in pacchetto: completamente utilizzabile.
    • App WinUI: 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 dovresti attendere una chiamata asincrona se l'app è in esecuzione in un STA. Per le app Windows Form e WinUI C#, è possibile dichiarare Main come asincrona, se necessario. Per le app C++ WinUI 3 e C# WPF, 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 ulteriori informazioni, vedi Instanziazione dell'app con l'API del ciclo di vita dell'app.

  • Notifiche di potenza/stato

Problema noto:

Le associazioni tipo di file codificano erroneamente %1 diventando %251 quando si imposta il modello della riga di comando del gestore dei verbi, il che provoca l'arresto anomalo delle app Win32 non impacchettate. È 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 contengono un bug critico. Se è già stata installata una di queste anteprime, vedere come risolvere il problema.

  • Questa versione introduce i modelli Blank App, Packaged (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 generare il progetto: "Il progetto non sa come eseguire il profilo nome del progetto". Per risolvere questo problema, installare l'estensione MSIX Packaging Tools a progetto singolo.

    • Modello C# per Visual Studio 2019 e Visual Studio 2022. Quando si tenta di eseguire o 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 Deploy in Configuration Manager." Per risolvere questo problema, abilitare la distribuzione per il progetto in Configuration Manager. Per istruzioni dettagliate, vedere creare il 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.

    • Il modello C++ per Visual Studio 2022 versione 17.0 rilascia fino a 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 Sperimentale nella versione 1.0 Preview 2. L'attributo Sperimentale 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: x86o x64arm64.

  • I progetti C# che usano la versione 1.0 Preview 2 devono usare il seguente .NET SDK: .NET 6 SDK o versione successiva (vedere Scaricare .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):An alternative to DispatcherQueue.TryEnqueue (for resuming execution on the dispatcher queue thread) is to use the resume_foreground helper function in the Windows Implementation Library (WIL):

    1. Aggiungere un riferimento al progetto al pacchetto NuGet Microsoft.Windows.ImplementationLibrary .
    2. Aggiungere #include <wil/cppwinrt_helpers.h> all'oggetto pch.h.
    3. Aggiungere #include <winrt/Microsoft.UI.Dispatching.h> all'oggetto pch.h.
    4. Ora co_await wil::resume_foreground(your_dispatcherqueue);.

Versione 1.0 Preview 1 (1.0.0-preview1)

Importante

La versione 1.0 Preview 1 e Preview 2 contengono un bug critico. Se è già stata installata una di queste anteprime, vedere come risolvere il problema.

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

Le sezioni seguenti descrivono funzionalità, limitazioni e problemi noti nuovi e aggiornati per 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 risolti: per l'elenco completo dei problemi risolti in questa versione, vedere il repository GitHub.

Per altre info o per iniziare a sviluppare con WinUI 3, vedi:

Finestra (1.0.0-preview1)

Questa versione porta l'API Windowing introdotta in Sperimentale 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. In questo modo uno sviluppatore può osservare le modifiche nella topologia di visualizzazione ed enumerare DisplayAreas attualmente definito nel sistema.
  • AppWindow supporta ora l'impostazione dell'icona della finestra tramite il metodo SetIcon e 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 (sia in pacchetto che non in pacchetto).
  • Windows App SDK attualmente non fornisce metodi per collegare il contenuto del framework dell'interfaccia utente a un'AppWindow; è possibile usare i metodi di accesso di interoperabilità HWND.
  • 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. Questa funzionalità è di livello inferiore.

Per altre info, vedi Gestire le finestre delle app (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 alle 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 nel futuro per migliorare la latenza e ottenere 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" presente in e suddividendo l'oggetto CoreCursor in CoreCursoroggetti separati.
  • Aggiornamenti alle API InputCursor .
  • GestureRecognizer è stato spostato da sperimentale a Microsoft.UI.Input.
  • PointerPoint è passato dalla fase sperimentale a Microsoft.UI.Input.
  • L'input tramite mouse, tocco e penna è completamente supportato per la funzionalità di trascinamento e rilascio in 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.
  • 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 Position e ContactRect invece. 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 contengono un bug critico. Se è già stata installata una di queste anteprime, vedere come risolvere il problema.

  • Per impostazione predefinita, i progetti creati usando l'app vuota C++, in pacchetto con WAP (WinUI 3 in Desktop) riscontrano l'errore di compilazione seguente: 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):An alternative to DispatcherQueue.TryEnqueue (for resuming execution on the dispatcher queue thread) is to use the resume_foreground helper function in the Windows Implementation Library (WIL):

    1. Aggiungere un riferimento al progetto al pacchetto NuGet Microsoft.Windows.ImplementationLibrary .
    2. Aggiungere #include <wil/cppwinrt_helpers.h> all'oggetto pch.h.
    3. Aggiungere #include <winrt/Microsoft.UI.Dispatching.h> all'oggetto pch.h.
    4. Ora co_await wil::resume_foreground(your_dispatcherqueue);.

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

  • Le app .NET devono essere destinate alla build 18362 o successiva: Il TFM deve essere impostato su net6.0-windows10.0.18362 o versione successiva e il <TargetPlatformVersion> del progetto di creazione del pacchetto deve essere impostato su 18362 o versione successiva. Per altre informazioni, vedere il noto problema su GitHub.

  • I progetti C# che usano la versione 1.0 Preview 1 devono usare .NET SDK seguente: .NET 6 SDK o versione successiva (vedere Scaricare .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.

Versione 1.0 Sperimentale (1.0.0-experimental1)

WinUI 3

Questa versione di WinUI 3 è incentrata sulla creazione di nuove funzionalità per la versione 1.0 stabile e la correzione di bug.

  • Nuove funzionalità: supporto per la visualizzazione di contentDialog per finestra anziché per thread.
  • Bug: per l'elenco completo dei bug risolti in questa Versione, consultare il repository GitHub.
  • Esempi: Per visualizzare i controlli e le funzionalità WinUI 3 in azione, è possibile clonare e avviare l'applicazione della raccolta WinUI 3 da GitHub. Oppure puoi scaricare l'applicazione dal Microsoft Store.

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

Notifiche push (funzionalità sperimentale)

Questa versione introduce un'API per le notifiche push che può essere usata dalle app desktop in pacchetto con identità basate sulla registrazione delle app di Azure. Per usare questa funzionalità, è necessario iscriversi all'anteprima privata.

Limitazioni importanti:

  • Le notifiche push sono supportate solo nelle app in pacchetto MSIX in esecuzione in Windows 10 versione 2004 (build 19041) o versioni successive.
  • Microsoft si riserva il diritto di disabilitare o revocare le app dalle notifiche push durante l'anteprima privata.
  • Microsoft non garantisce l'affidabilità o la latenza delle notifiche push.
  • Durante l'anteprima privata, il volume delle notifiche push è limitato a 1 milione al mese.

Per altre informazioni, vedere Panoramica delle notifiche push.

Windowing

Questa versione include gli aggiornamenti alle API di gestione delle finestre. Si tratta di un set di API di windows di alto livello, incentrate sulla classe AppWindow, che consente scenari di finestre facili da usare che si integrano bene con l'esperienza utente di Windows e altre app. Questo è simile, ma non identico a, l'AppWindow UWP.

Limitazioni importanti:

  • Questa versione di AppWindow è attualmente disponibile solo per le app Win32 (in pacchetto e non in pacchetto).
  • La Windows App SDK attualmente non fornisce metodi per collegare il contenuto del framework dell'interfaccia utente a un AppWindow; sei limitato a usare i metodi di accesso interop HWND.
  • L'API Windowing non funzionerà attualmente in Windows versione 1809 e 1903 per AMD64.

Per altre informazioni, vedere Gestire le finestre delle app (Windows App SDK) .

Distribuzione per app non in pacchetto

Questa versione introduce aggiornamenti alla funzionalità di dipendenze dinamiche , inclusa l'API bootstrapper .

Limitazioni importanti:

  • La funzionalità delle dipendenze dinamiche è supportata solo per le app non in pacchetto.
  • I chiamanti con privilegi elevati non sono supportati.

Per altre informazioni, vedere gli articoli seguenti:

Altre limitazioni e problemi noti
  • Nessun supporto per qualsiasi configurazione di compilazione della CPU: Windows App SDK viene scritto nel codice nativo e pertanto non supporta Qualsiasi configurazione di compilazione della CPU. I modelli WinUI 3 in Visual Studio consentono solo compilazioni specifiche per architettura. Quando si aggiunge l'SDK di Windows App a un'applicazione o a un componente .NET esistente che supporta Qualsiasi CPU, è necessario specificare l'architettura desiderata: x86, x64 o arm64.
  • Le app .NET devono essere destinate alla build 18362 o successiva: Il TFM deve essere impostato su net6.0-windows10.0.18362 o versione successiva e il <TargetPlatformVersion> del progetto di creazione del pacchetto deve essere impostato su 18362 o versione successiva. Per altre informazioni, vedere il noto problema su GitHub.
  • Le app C# che utilizzano la versione 1.0 Sperimentale devono usare uno tra i seguenti SDK .NET:
  • Last updated on