Versionsinformation för förhandsversionskanalen av Windows App SDK 1.0

Förhandsgranskningskanalen innehåller versioner av Windows App SDK med förhandsgranskningskanalfunktioner i sena utvecklingsstadier. Förhandsversioner innehåller inte experimentella funktioner och API:er, men kan fortfarande vara utsatta för förändringar som bryter kompatibilitet innan nästa stabila version.

Viktiga länkar:

• Om du vill uppgradera en befintlig app från en äldre version av Windows App SDK till en nyare version kan du läsa Uppdatera befintliga projekt till den senaste versionen av Windows App SDK.
• Dokumentation om förhandsversioner finns i Installera verktyg för förhandsversioner och experimentella kanaler i Windows App SDK.

Senaste förhandsversion av kanalen:

• Senaste versionsinformation för förhandskanalen för Windows App SDK

Senaste stabila kanalversionen:

• Senaste viktig information om stabil kanal för Windows App SDK-

Version 1.0 Förhandsversion 3 (1.0.0-preview3)

Förhandsversion 3 är den senaste versionen av förhandsgranskningskanalen för version 1.0 av Windows App SDK. Förhandsversion 3 stöder alla förhandsgranskningskanalfunktioner.

Ladda ned 1.0 Förhandsversion 3 Visual Studio-tillägg (VSIX)

I tabellen nedan kan du ladda ned Visual Studio-tilläggen (VSIX) för versionen 1.0 Preview 3. Alla versioner finns i Senaste nedladdningar av Windows App SDK. Om du inte redan har gjort det börjar du med att konfigurera utvecklingsmiljön med hjälp av stegen i Installera verktyg för Windows App SDK.

Tilläggen nedan är skräddarsydda för ditt programmeringsspråk och din version av Visual Studio.

I följande avsnitt beskrivs nya och uppdaterade funktioner, begränsningar och kända problem för förhandsversionen 3 av 1.0.

WinUI 3 (1.0.0-preview3)

Vi stöder nu distribution av WinUI 3-appar utan MSIX-paketering. Se Skapa ditt första WinUI 3-projekt (Windows App SDK) för att konfigurera ditt WinUI 3-program för att stödja uppackad distribution.

Viktiga begränsningar:

• Uppackade WinUI 3-program stöds endast i Windows version 1909 och senare.
• Uppackade WinUI 3-program stöds på x86 och x64; arm64-stöd läggs till i nästa stabila version.
• MSIX-paketeringsverktyg med ett projekt för Visual Studio 2019 eller Visual Studio 2022 krävs för opackade appar.
• I en uppackad app kan du få en uppmaning om att installera .NET 3.5. Om du gör det kan du ignorera det.
• Vissa API:er stöds för närvarande inte i uppackade appar. Vi vill åtgärda detta i nästa stabila version. Några exempel:
  • Applikationsdata
  • StorageFile.GetFileFromApplicationUriAsync
  • ApiInformation (stöds inte i Windows 10)
  • Paket.Aktuellt
• Kontrollerna ListView, CalendarView och GridView använder felaktiga format och vi vill åtgärda detta i nästa stabila version.

Mer information, eller för att komma igång med att utveckla med WinUI 3, finns i:

• WinUI
• Skapa ditt första WinUI 3-projekt (Windows App SDK)

Andra begränsningar och kända problem:

• Uppackade appar stöds inte i Windows 10 version 1809. Vi vill åtgärda detta i nästa version i den stabila kanalen.

• C#-enkelprojekt-MSIX-app kompileras inte om C++ UWP-verktyg inte är installerade. Om du har ett C#-MSIX-projekt för enstaka projekt måste du installera den valfria komponenten C++ (v14x) Universal Windows Platform Tools.

• Den här versionen introducerar Tom applikation, Paketerad (WinUI 3 på Desktop) projektmallar för C# och C++. Med de här mallarna kan du skapa din app i ett MSIX-paket utan att använda ett separat paketeringsprojekt (se Paketera din app med MSIX med ett enda projekt). Dessa mallar har några kända problem i den här versionen:

  • Menyalternativet Publicera saknas tills du startar om Visual Studio. När du skapar en ny app i både Visual Studio 2019 och Visual Studio 2022 med hjälp av Tom app, Paketerad (WinUI 3 i Desktop) projektmall visas inte kommandot för att publicera projektet på menyn förrän du stänger och öppnar Visual Studio igen.

  • Fel vid tillägg av C++-projektreferenser för statiskt/dynamiskt bibliotek till C++-appar med hjälp av MSIX-paketering för enfunktionsprojekt. Visual Studio visar ett fel om att projektet inte kan läggas till som referens eftersom projekttyperna inte är kompatibla.

  • Fel vid referens till en anpassad användarkontroll i ett klassbiblioteksprojekt. Programmet kraschar med felet att systemet inte kan hitta den angivna sökvägen.

  • C# eller C++-mall för Visual Studio 2019. När du försöker skapa projektet får du felet "Projektet vet inte hur profilprojektets namn ska köras". Lös problemet genom att installera tillägget MSIX Packaging Tools för enskilda projekt.

  • C#-mall för Visual Studio 2019 och Visual Studio 2022. I Visual Studio när du Starta felsökning eller Starta utan att felsöka, om din app inte distribueras och körs (och det inte finns någon feedback från Visual Studio) klickar du på projektnoden i Solution Explorer för att välja den och försök på nytt.

  • C#-mall för Visual Studio 2019 och Visual Studio 2022. Följande fel uppstår när du försöker köra eller felsöka projektet på utvecklingsdatorn: "Projektet måste distribueras innan vi kan felsöka. Aktivera Distribuera i Configuration Manager." Lös problemet genom att aktivera distribution för projektet i Configuration Manager. Detaljerade anvisningar finns i Skapa ditt första WinUI 3-projekt (Windows App SDK).

  • C++-mall för Visual Studio 2022 version 17.0 släpper upp till Förhandsversion 4. Du får följande fel första gången du försöker köra projektet: "Det uppstod distributionsfel". Lös problemet genom att köra eller distribuera projektet en andra gång. Det här problemet åtgärdas i Visual Studio 2022 version 17.0 Preview 7.

• Inget stöd för buildkonfigurationen Any CPU: När du lägger till Windows App SDK- till ett befintligt .NET-program eller -komponent som stöder Any CPU-, måste du ange önskad arkitektur: x86, x64 eller arm64.

• C#-projekt med 1.0 Preview 3 måste använda följande .NET SDK: .NET 6 SDK eller senare (se Ladda ned .NET och .NET 5 når supporten upphör den 10 maj 2022).

• Ett alternativ till DispatcherQueue.TryEnqueue (för att återuppta körningen på Dispatcher-kö-tråden) är att använda funktionen resume_foreground som finns i hjälpverktyget Windows Implementation Library (WIL):

  1. Lägg till en referens till projektet i NuGet-paketet Microsoft.Windows.ImplementationLibrary .
  2. Lägg till #include <wil/cppwinrt_helpers.h> till din pch.h.
  3. Lägg till #include <winrt/Microsoft.UI.Dispatching.h> till din pch.h.
  4. Nu co_await wil::resume_foreground(your_dispatcherqueue);.

Viktigt problem som påverkar 1.0 Förhandsversion 1 och Förhandsversion 2

Version 1.0 Förhandsversion 1 och Förhandsversion 2 av Windows App SDK innehåller en mekanism för att rensa eventuella miljövariabeländringar som görs av en paketerad app när appen avinstalleras. Den här funktionen är i ett experimentellt tillstånd och den första versionen innehåller en känd bugg som kan skada systemvariabeln PATH-miljö .

Förhandsversion 1 och förhandsversion 2 skadar alla PATH-miljövariabler som innehåller expansionstecknet .% Detta inträffar när en paketerad app avinstalleras, oavsett om appen använder Windows App SDK.

Se även problem med skadade PATH-miljövariabler.

Detaljer

Systemets PATH-post lagras i värdet Sökväg i följande nyckel i Windows-registret:

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

Om du startar Registereditorn (regedit.exe) kan du kopiera och klistra in sökvägen ovan i adressfältet (direkt under menyraden) och tryck på Retur för att hitta nyckeln.

Path värdet för nyckeln bör vara av typen REG_EXPAND_SZ, men felet ändrar det till REG_SZ. Och det gör att system-PATH-miljövariabeln är oanvändbar om den innehåller variabelexpansionstecknet .%

Berörda versioner

• SDK för Windows-appar 1.0 förhandsversion 1 (1.0.0-preview1)
• SDK för Windows-appar 1.0 förhandsversion 2 (1.0.0-preview2)

Minskning av påverkan

Utför följande steg för att få tillbaka datorn i ett bra tillstånd:

1. Kontrollera om SÖKVÄGEN i registret är skadad och återställ den i så fall genom att köra skriptet nedan.

   Du kan utföra steg 1 med följande Windows PowerShell-skript (PowerShell Core fungerar inte). Kör den upphöjd.

   # 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. Avinstallera alla appar som använder Windows App SDK 1.0 Preview1 eller Preview2 (se skriptet nedan).

3. Avinstallera Windows App SDK 1.0 Preview1/Preview2-paketen, inklusive paketet som innehåller buggen (se skriptet nedan).

   Du kan utföra steg 2 och 3 med följande Windows PowerShell-skript (PowerShell Core fungerar inte). Kör den upphöjd.

   # 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
   

Korrigering i Windows App SDK 1.0 Preview 3

Funktionen som gör att PATH-miljövariabeln skadas tas bort i den kommande versionen av Windows App SDK 1.0 Preview 3. Det kan återinföras vid ett senare tillfälle, när alla buggar har åtgärdats och testats noggrant.

Vi rekommenderar att du använder version 1.0 Preview 3.

Version 1.0 Förhandsversion 2 (1.0.0-preview2)

Det här är den senaste versionen av förhandsgranskningskanalen för version 1.0. Den stöder alla förhandsgranskningskanalfunktioner.

I följande avsnitt beskrivs nya och uppdaterade funktioner, begränsningar och kända problem för den här versionen.

WinUI 3 (1.0.0-preview2)

Nya uppdateringar:

• Kontrollerna har uppdaterats för att återspegla de senaste Windows-stilarna från WinUI 2.6.
• Stöd för MSIX med ett projekt finns.
• WinUI 3-paketet kan nu rikta in sig på version 17763 och senare. För mer information, se ärende , #921,.
• Verktygsfältet i appen stöds. Den kommande versionen av Visual Studio 17.0 Preview 5, som blir tillgänglig i slutet av oktober, krävs för verktygsfältet i appen och det befintliga stödet för Hot Reload/Live Visual Tree.

Buggen har åtgärdats: WebView2Runtime-text är nu lokaliserad.

Mer information eller för att komma igång med att utveckla med WinUI 3 finns i:

• WinUI
• Skapa ditt första WinUI 3-projekt (Windows App SDK)

Fönster (1.0.0-preview2)

Den här versionen introducerar uppdateringar av klassen AppWindow . Inga större nya funktioner har lagts till i den här versionen, men det finns ändringar i metodnamn, egenskaper och vissa returvärden har tagits bort. Se dokumentationen och exemplen för detaljerade uppdateringar. Om du arbetade med AppWindow i versionerna 1.0 Experimental eller 1.0 Preview 1 kan du förvänta dig några ändringar i koden.

Nya uppdateringar:

• Klassen AppWindowConfiguration har tagits bort. Egenskaperna för den här klassen är nu tillgängliga i själva AppWindow eller i föredragshållarklasserna .
• De flesta bool-returvärden för WinRT API-metoderna inom det här området har tagits bort och är nu void eftersom dessa metoder alltid lyckas.
• C# ImportDll-anropen behövs inte längre för GetWindowIdFromWindow och GetWindowFromWindowId. Använd de .NET-omslutningsmetoder som är tillgängliga i klassen Microsoft.UI.Win32Interop i stället.

Viktiga begränsningar:

• Windows App SDK tillhandahåller för närvarande inte metoder för att koppla UI Framework-innehåll till en AppWindow. du är begränsad till att använda HWND-interop-åtkomstmetoderna.
• Anpassning av fönsterrubrikfältet fungerar endast på Windows 11. Använd metoden IsCustomizationSupported för att kontrollera funktionsstöd för anpassning av titelrad. Vi har för avsikt att sänka den här funktionen.

Mer information finns i Hantera appfönster (Windows App SDK).

Indata (1.0.0-förhandsvisning2)

Nya uppdateringar:

• Förbättrat stöd för inmatning med precisionspekplatta.

Viktiga begränsningar:

• Alla static factory-funktioner för PointerPoint har tagits bort: GetCurrentPoint, GetCurrentPointTransformed, GetIntermediatePoints och GetIntermediatePointsTransformed.
• Windows App SDK stöder inte hämtning av PointerPoint objekt med pekar-ID. I stället kan du använda medlemsfunktionen PointerPointGetTransformedPoint för att hämta en transformerad version av ett befintligt PointerPoint-objekt . För mellanliggande punkter kan du använda PointerEventArgs medlemsfunktionerna GetIntermediatePoints och GetTransformedIntermediatePoints. Mer information finns i dokumentationen.

MRT-kärna (1.0.0-preview2)

Nya uppdateringar:

• Apputvecklare kan nu välja bort en bildfil eller en RESW-fil från att indexeras i PRI-filen i .NET-projekt. Se ärende 980 för mer information.

Viktiga begränsningar:

• I .NET-projekt indexeras inte resursfiler som kopierats till projektmappen på F5 om appen redan har skapats. För att lösa problemet, återskapa appen. Mer information finns i ärende 1503.
• I .NET-projekt indexeras inte befintliga resursfiler som läggs till från en extern mapp utan manuell inställning av byggåtgärden. Du kan lösa det här problemet genom att ange byggåtgärden i Visual Studio: Innehåll för bildfiler och PRIResource för RESW-filer. Se ärende 1504 för mer information.

Implementering för opackade appar

Nya funktioner:

• Windows App SDK 1.0 Preview 2 introducerar en .NET-omslutning för bootstrapper-API:et (se Använda Windows App SDK-körmiljön för appar som paketeras med externt läge eller utan paket). Bootstrapper-API:et är en uppsättning inbyggda C/C++-funktioner som opaketerade appar måste använda för att dynamiskt ta ett beroende av Windows App SDK-ramverkspaketet under körning. .NET-omslutningen är ett enklare sätt att anropa bootstrapper-API:et från .NET-appar, inklusive Windows Forms och WPF-appar. .NET-omslutningen för bootstrapper-API:et är tillgänglig i Microsoft.WindowsAppRuntime.Bootstrap.Net.dll assembly, vilken är lokal för ditt appprojekt. Mer information om .NET-omslutningen finns i .NET-omslutningsbiblioteket.
• Paketerade appar kan nu använda distributions-API:et för att få huvud- och singleton MSIX-paket installerade på datorn. Huvud- och singleton-paketen är en del av det ramverkspaket som installeras med appen, men på grund av en begränsning med Windows-programmodellen måste paketerade appar ta det här ytterligare steget för att få paketen installerade. Mer information om hur distributions-API:et fungerar finns i Distributionsguide för Windows App SDK för ramverksberoende paketerade appar.

Viktiga begränsningar:

• .NET-omslutningen för bootstrapper-API:et är endast avsedd att användas av uppackade .NET-program för att förenkla åtkomsten till Windows App SDK.
• Endast MSIX-paketerade appar som är fullständigt betrodda eller har den begränsade funktionen packageManagement har behörighet att använda distributions-API:et för att installera huvud- och singleton-paketberoenden. Stöd för paketerade appar med partiellt förtroende kommer i senare versioner.
• När F5 testar en x86-app som använder metoden DeploymentManager.Initialize i ett x64-system kontrollerar du att x64-ramverket först installeras genom att köra WindowsAppRuntimeInstall.exe. Annars uppstår ett NOT_FOUND fel på grund av att Visual Studio inte distribuerar x64-ramverket, vilket normalt sker genom butiksdistribution eller sidoladdning.

Appens livscykel

De flesta funktioner för applivscykel finns redan på UWP-plattformen och har förts in i Windows App SDK för användning av skrivbordsapptyper, särskilt uppackade konsolappar, Win32-appar, Windows Forms-appar och WPF-appar. Windows App SDK-implementeringen av dessa funktioner kan inte användas i UWP-appar, eftersom det finns motsvarande funktioner i själva UWP-plattformen.

Icke-UWP-appar kan också paketeras i MSIX-paket. Även om dessa appar kan använda några av funktionerna i Windows App SDK App Lifecycle måste de använda manifestmetoden där detta är tillgängligt. De kan till exempel inte använda Windows App SDK RegisterForXXXActivation-API :er och måste i stället registrera sig för omfattande aktivering via manifestet.

Alla begränsningar för paketerade appar gäller även för WinUI 3-appar som paketeras. och det finns ytterligare överväganden enligt beskrivningen nedan.

Viktiga överväganden:

• Omfattande aktivering: GetActivatedEventArgs

  • Opacketerade appar: Kan användas fullt ut.
  • Paketerade appar: Användbara, men de här apparna kan också använda plattformen GetActivatedEventArgs. Observera att plattformen definierar Windows.ApplicationModel.AppInstance medan Windows App SDK definierar Microsoft.Windows.AppLifecycle.AppInstance. Och även om UWP-appar kan använda ActivatedEventArgs-klasserna, till exempel FileActivatedEventArgs och LaunchActivatedEventArgs, måste appar som använder funktionen Windows App SDK AppLifecycle använda gränssnitten istället för klasserna (t.ex. IFileActivatedEventArgs, ILaunchActivatedEventArgs, och så vidare).
  • WinUI 3-appar: WinUI 3:s App.OnLaunched tilldelas ett Microsoft.UI.Xaml.LaunchActivatedEventArgs, medan plattformen GetActivatedEventArgs returnerar ett Windows.ApplicationModel.IActivatedEventArgs, och WindowsAppSDK GetActivatedEventArgs returnerar ett Microsoft.Windows.AppLifecycle.AppActivationArguments objekt som kan representera en plattform LaunchActivatedEventArgs.
  • Mer information finns i Omfattande aktivering med appens livscykel-API.

• Registrera/avregistrera för omfattande aktivering

  • Opacketerade appar: Kan användas fullt ut.
  • Paketerade appar: Är inte användbara. Använd istället appens MSIX-manifest.
  • Mer information finns i Omfattande aktivering med appens livscykel-API.

• Enkel-/flera instanser

  • Opacketerade appar: Kan användas fullt ut.
  • Paketerade appar: Kan användas fullt ut.
  • WinUI 3-appar: Om en app vill identifiera andra instanser och omdirigera en aktivering måste den göra det så tidigt som möjligt och innan du initierar några fönster osv. För att aktivera detta måste appen definiera DISABLE_XAML_GENERATED_MAIN och skriva en anpassad main (C#) eller WinMain (C++) där den kan identifiera och omdirigera.
  • RedirectActivationToAsync är ett asynkront anrop och du bör inte vänta på ett asynkront anrop om din app körs i en STA. För Windows Forms- och C#WinUI 3-appar kan du deklarera Main som asynkron, om det behövs. För C++ WinUI 3- och C#WPF-appar kan du inte deklarera Main som asynkron, så i stället måste du flytta omdirigeringsanropet till en annan tråd för att säkerställa att du inte blockerar STA.
  • Mer information finns i App-instansiering med API för applivscykel.

• Meddelanden om ström/driftstatus

  • Opacketerade appar: Kan användas fullt ut.
  • Paketerade appar: Kan användas fullt ut.
  • Mer information finns i Energisparfunktioner med appens livscykel-API.

Känt problem:

Filtypsassociationer kodar felaktigt %1 till %251 när verbhanterarens kommandoradsmall anges, vilket leder till att uppackade Win32-appar kraschar. Du kan manuellt ändra registervärdet till %1 istället, som en delvis lösning. Om målfilens sökväg har ett utrymme i den misslyckas den fortfarande och det finns ingen lösning för det scenariot.

Andra begränsningar och kända problem:

• Version 1.0 Förhandsversion 1 och Förhandsversion 2 innehåller en kritisk bugg. Om du redan har installerat någon av dessa förhandsversioner kan du läsa hur du löser problemet. Vi rekommenderar att du använder version 1.0 Preview 3 i stället.

• Den här versionen introducerar Tom app, Paketerad (WinUI 3 i Desktop) mallar för C#- och C++-projekt. Med de här mallarna kan du skapa din app i ett MSIX-paket utan att använda ett separat paketeringsprojekt. Dessa mallar har några kända problem i den här versionen:

  • C#-mall för Visual Studio 2019. Du får felet när du försöker skapa projektet: "Projektet vet inte hur profilprojektets namn ska köras". Lös problemet genom att installera tillägget MSIX Packaging Tools för enskilda projekt.

  • C#-mall för Visual Studio 2019 och Visual Studio 2022. Följande fel uppstår när du försöker köra eller felsöka projektet på utvecklingsdatorn: "Projektet måste distribueras innan vi kan felsöka. Aktivera Distribuera i Configuration Manager." Lös problemet genom att aktivera distribution för projektet i Configuration Manager. Detaljerade anvisningar finns i Skapa ditt första WinUI 3-projekt (Windows App SDK).

  • C++-mall för Visual Studio 2019 och Visual Studio 2022. I den här versionen är dessa projekt begränsade till att anropa delmängden av Win32-API:er som kan anropas av UWP-appar. Den tomma appen, paketerad med WAP (WinUI 3 i Desktop) mall påverkas inte av det här problemet.

  • C++-mall för Visual Studio 2022 version 17.0 släpper upp till Förhandsversion 4. Du får följande fel första gången du försöker köra projektet: "Det uppstod distributionsfel". Lös problemet genom att köra eller distribuera projektet en andra gång. Det här problemet åtgärdas i Visual Studio 2022 version 17.0 Preview 5.

• API för push-meddelanden (Namnrymden Microsoft.Windows.PushNotifications) ingår felaktigt i 1.0 Preview 2-versionen. Det här är fortfarande en experimentell funktion och för att du ska kunna använda den måste du installera den experimentella versionen 1.0 i stället. Den här funktionen tas bort från den kommande versionen av 1.0.

• Applivscykel-API (Microsoft.Windows.AppLifecycle-namnområde) innehåller felaktigt attributet Experimental i versionen 1.0 Preview 2. Det experimentella attributet tas bort från det här API:et i nästa version.

• Inget stöd för buildkonfigurationen Any CPU: När du lägger till Windows App SDK- till ett befintligt .NET-program eller -komponent som stöder Any CPU-, måste du ange önskad arkitektur: x86, x64 eller arm64.

• C#-projekt med 1.0 Preview 2 måste använda följande .NET SDK: .NET 6 SDK eller senare (se Ladda ned .NET och .NET 5 når supporten upphör den 10 maj 2022).

• Ett alternativ till DispatcherQueue.TryEnqueue (för att återuppta körningen på Dispatcher-kö-tråden) är att använda funktionen resume_foreground som finns i hjälpverktyget Windows Implementation Library (WIL):

  1. Lägg till en referens till projektet i NuGet-paketet Microsoft.Windows.ImplementationLibrary .
  2. Lägg till #include <wil/cppwinrt_helpers.h> till din pch.h.
  3. Lägg till #include <winrt/Microsoft.UI.Dispatching.h> till din pch.h.
  4. Nu co_await wil::resume_foreground(your_dispatcherqueue);.

Version 1.0 Förhandsversion 1 (1.0.0-preview1)

Det här är den första versionen av förhandsgranskningskanalen för version 1.0. Den stöder alla förhandsgranskningskanalfunktioner.

I följande avsnitt beskrivs nya och uppdaterade funktioner, begränsningar och kända problem för den här versionen.

WinUI 3 (1.0.0-preview1)

Den här versionen av WinUI 3 fokuserar på att bygga mot 1.0 med felkorrigeringar.

• Nya funktioner: Inga nya funktioner i förhandsversion 1.
• Åtgärdat problem: En fullständig lista över problem som åtgärdas i den här versionen finns i vår GitHub-lagringsplats.

Mer information eller för att komma igång med att utveckla med WinUI 3 finns i:

• WinUI
• Skapa ditt första WinUI 3-projekt (Windows App SDK)

Fönster (1.0.0-preview1)

Den här versionen tar fönsterhanterings-API vi introducerade i Experimentell 1 till ett förhandsvisningsläge. Det finns inga större nya funktionsområden i den här versionen eftersom den fokuserar på buggfix, stabilitet och justeringar av API-signaturen. De anmärkningsvärda ändringarna och tilläggen beskrivs nedan.

Nya funktioner:

• DisplayAreaWatcher har lagts till i API:erna för fönster. Detta gör att en utvecklare kan observera ändringar i visningstopologin och räkna upp DisplayAreas som för närvarande definieras i systemet.
• AppWindow har nu stöd för att ange fönsterikonen via Metoden SetIcon , och AppWindowTitleBar har nu stöd för att välja om fönsterikonen ska visas/döljas tillsammans med systemmenyn via egenskapen IconShowOptions .

Viktiga begränsningar:

• Den här versionen av AppWindow är för närvarande endast tillgänglig för Win32-appar (både paketerade och uppackade).
• Windows App SDK tillhandahåller för närvarande inte metoder för att koppla UI Framework-innehåll till en AppWindow. du är begränsad till att använda HWND-interop-åtkomstmetoderna.
• Anpassning av fönsterrubrikfältet fungerar endast på Windows 11. Använd metoden IsCustomizationSupported för att kontrollera funktionsstöd för anpassning av titelrad. Vi har för avsikt att sänka den här funktionen.

Mer information finns i Hantera appfönster (Windows App SDK).

Indata (1.0.0-preview1)

Den här versionen innehåller några nya funktioner i indata-API:et. De anmärkningsvärda ändringarna och tilläggen beskrivs nedan.

Nya funktioner och uppdateringar:

• PointerPredictor ger känsliga program för svarstid för indata, till exempel pennanteckningar, möjlighet att förutsäga platser för indatapunkter upp till 15 ms i framtiden för att uppnå bättre svarstid och smidig animering.
• PenDeviceInterop gör det möjligt att hämta en referens till Windows.Devices.Input.PenDevice genom att använda metoden FromPointerPoint.
• InputCursor ger en tydlig skillnad mellan förinställda systemmarkörtyper och anpassade markörtyper genom att ta bort typen "Anpassad" som finns i CoreCursoroch dela upp CoreCursor objektet i separata objekt.
• Uppdateringar av InputCursor-API:er.
• GestureRecognizer flyttades från experimentet till Microsoft.UI.Input.
• PointerPoint har flyttats från experimentell till Microsoft.UI.Input.
• Mus-, touch- och penningångar stöds fullt ut för dra och släpp i WinUI 3.

Viktiga begränsningar:

• Denna version av API:er för inmatning har kända problem med Windows version 1809.
• MRT Core stöds ännu inte av någon undertyp av InputCursor.
• Direkt användning av plattformens SDK API Windows.UI.Core.CoreDragOperation fungerar inte med WinUI 3-program.
• PointerPoint-egenskaperna RawPosition och ContactRectRaw togs bort eftersom de refererade till icke-förutsagda värden, som var samma som normalvärdena i operativsystemet. Använd Position och ContactRect i stället. Pekarförutsägelse hanteras nu med API-objektet Microsoft.UI.Input.PointerPredictor.

MRT-kärna (1.0.0-preview1)

Från och med version 1.0 Förhandsversion 1 har MRT Core-API:er flyttats från namnområdet Microsoft.ApplicationModel.Resources till namnområdet Microsoft.Windows.ApplicationModel.Resources .

Andra begränsningar och kända problem:

• Version 1.0 Förhandsversion 1 och Förhandsversion 2 innehåller en kritisk bugg. Om du redan har installerat någon av dessa förhandsversioner kan du läsa hur du löser problemet. Vi rekommenderar att du använder version 1.0 Preview 3 i stället.

• Projekt som skapade med hjälp av Tom app för C++, paketerad med WAP (WinUI 3 i Desktop) projektmall påträffar som standard följande byggfel: fatal error C1083: Cannot open include file: 'winrt/microsoft.ui.dispatching.co_await.h': No such file or directory. Lös problemet genom att ta bort följande kodrad från pch.h-filen . Det här problemet åtgärdas i nästa version.

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

• Ett alternativ till DispatcherQueue.TryEnqueue (för att återuppta körningen på Dispatcher-kö-tråden) är att använda funktionen resume_foreground som finns i hjälpverktyget Windows Implementation Library (WIL):

  1. Lägg till en referens till projektet i NuGet-paketet Microsoft.Windows.ImplementationLibrary .
  2. Lägg till #include <wil/cppwinrt_helpers.h> till din pch.h.
  3. Lägg till #include <winrt/Microsoft.UI.Dispatching.h> till din pch.h.
  4. Nu co_await wil::resume_foreground(your_dispatcherqueue);.

• Inget stöd för Any CPU build-konfiguration: Windows App SDK är skrivet i inbyggd kod och stöder därför inte Any CPU build-konfigurationer. WinUI 3-mallar i Visual Studio tillåter endast arkitekturspecifika byggen. När att lägga till Windows App SDK- till ett befintligt .NET-program eller -komponent som stöder Alla CPU-måste du ange önskad arkitektur: x86, x64 eller arm64.

• .NET-appar måste rikta in sig på version 18362 eller senare: Din TFM måste anges till net6.0-windows10.0.18362 eller senare, och paketeringsprojektets <TargetPlatformVersion> måste anges till 18362 eller senare. För mer information, se det kända problemet på GitHub.

• C#-projekt som använder 1.0 Preview 1 måste använda följande .NET SDK: .NET 6 SDK eller senare (se Ladda ned .NET och .NET 5 når supporten upphör den 10 maj 2022).

• Uppackade appar stöds inte i Windows 10 version 1809: Detta bör lösas i nästa version.

Relaterade ämnen

• Senaste viktig information om stabil kanal för Windows App SDK-
• Senaste versionsinformation för experimentella kanalen för Windows App SDK
• Installera verktyg för Windows App SDK
• Skapa ditt första WinUI 3-projekt (Windows App SDK)
• Använda Windows App SDK i ett befintligt projekt
• Distributionsöversikt