Microsoft Windows App SDK 1.0 Stable utgitt, tilgjengelig for nedlasting (versjonsmerknader)

Etter flere forhåndsvisninger har Microsoft nettopp sluppet Windows App SDK 1.0.0 Stable, et verktøysett som gir utviklere av desktop-apper mulighet til å bygge apper med et moderne Windows-grensesnitt, APIer og plattformfunksjoner.

I denne utgivelsen la Microsoft til flere nye funksjoner fra Windows App SDK 0.8 og stabiliserte problemer fra 1.0 Preview-utgivelser.

[lwptoc title=”WindowsAppSDK 1.0 Stable” width=”30%” float=”right”]

WindowsUI 3

WinUI 3 er det opprinnelige brukeropplevelsen (UX) rammeverket for Windows App SDK.

Nye funksjoner og oppdateringer:

• Microsoft har lagt til nye kontroller (PipsPager, Expander, BreadcrumbBar) og oppdatert eksisterende kontroller for å gjenspeile de nyeste Windows-stilene fra WindowsUI 2.6.
• Enkeltprosjekt MSIX-pakke støttes i WinUI ved å lage en ny applikasjon ved å bruke malen "Blank App, Packaged...".
• Microsoft støtter nå distribusjon av WinUI 3-apper uten MSIX-pakke på Windows versjoner 1809 og nyere. Vennligst se Lag en WinUI 3 upakket skrivebordsapp for ytterligere informasjon.
• WinUI 3-prosjekter kan nå sette målversjonen ned til Windows 10, versjon 1809. Tidligere kunne de bare settes så lavt som versjon 1903.
• Verktøylinje i appen, Hot Reload og Live Visual Tree for WinUI-pakkede apper støttes i Visual Studio 2022 Preview 5 og GA.

Viktige begrensninger:

• Kjente problemer for både pakkede og upakkede WinUI-applikasjoner:
  • Kjøretidsfeil i C++-apper som refererer til en C++ Windows Runtime-komponent: For å løse det, legg til målet nedenfor på slutten av Windows Runtime Components .vcxproj:

    XMLKopier

    <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>
    

• Kjente problemer for WinUI-applikasjoner med enkeltprosjekt MSIX (Tom app, pakket mal):
  • Manglende pakke og publiser menyelement til du starter Visual Studio på nytt: Når du oppretter en ny app med enkeltprosjekt MSIX i både Visual Studio 2019 og Visual Studio 2022 ved hjelp av prosjektmalen Blank App, Packaged (WinUI 3 på skrivebordet), vises ikke kommandoen for å publisere prosjektet i menyen før du lukker og åpne Visual Studio på nytt.
  • AC#-appen med enkeltprosjekt MSIX vil ikke kompilere uten "C++ (v14x) Universal Windows Platform Tools" valgfri komponent installert. Utsikt Installer utviklerverktøy for ytterligere informasjon.
  • Potensiell kjøretidsfeil i en app med Single-project MSIX som bruker typer definert i en referert Windows Runtime Component: For å løse, legg til manuelt aktiverbare klasseinnlegg til appxmanifest.xml.
    • Den forventede feilen i C#-applikasjoner er "COMException: Class not registered (0x80040154 (REGDB_E_CLASSNOTREG)).
    • Den forventede feilen i C++/WinRT-applikasjoner er "winrt::hresult_class_not_registered".
• Kjente problemer for WinUI-applikasjoner uten MSIX-pakke (upakkede apper):
  • Noen API-er krever pakkeidentitet og støttes ikke i upakkede apper, for eksempel:
    • Applikasjonsdata
    • StorageFile.GetFileFromApplicationUriAsync
    • StorageFile.CreateStreamedFileFromUriAsync
    • ApiInformasjon (støttes ikke på Windows 10)
    • Package.Current
    • Enhver API i Windows.ApplicationModel.Resources namespace
    • Enhver API i Microsoft.Windows.ApplicationModel.Resources namespace
• Kjente problemer for pakke og distribuere WinUI-applikasjoner:
  • De Package kommandoen støttes ikke i WinUI-apper med enkeltprosjekt MSIX (tom app, pakket mal). Bruk i stedet Package & Publish kommando for å lage en MSIX-pakke.
  • For å lage en NuGet-pakke fra et C#-klassebibliotek med Pack kommando, sikre den aktive Configuration is Release.
  • De Pack kommandoen støttes ikke i C++ Windows Runtime Components for å lage en NuGet-pakke.

Vindu

Windows App SDK gir en AppWindow klasse som utvikler den forrige brukervennlige Windows.UI.WindowManagement.AppWindow forhåndsvisningsklassen og gjør den tilgjengelig for alle Windows-apper, inkludert Win32, WPF og WinForms.

Nye funksjoner

• AppWindow er et vindus-API på høyt nivå som muliggjør brukervennlige vindusscenarier som integreres godt med Windows-brukeropplevelsen og med andre apper. Representerer en abstraksjon på høyt nivå av en systemadministrert beholder med innholdet i en app. Dette er beholderen som innholdet ditt er vert for, og representerer enheten som brukere samhandler med når de endrer størrelse og flytter appen din på skjermen. For utviklere som er kjent med Win32, kan AppWindow sees på som en abstraksjon på høyt nivå av HWND.
• DisplayArea representerer en abstraksjon på høyt nivå av en HMONITOR, følger de samme prinsippene som AppWindow.
• DisplayAreaWatcher lar en utvikler observere endringer i skjermtopologien og telle opp DisplayAreas som for øyeblikket er definert i systemet.

Input

Dette er input-API-ene som støtter WinUI og gir en API-overflate på lavere nivå for utviklere for å oppnå mer avanserte input-interaksjoner.

Nye funksjoner

• Peker-APIer: PointerPoint, PointerPointPropertiesog PointEventArgs for å støtte henting av pekerhendelsesinformasjon med XAML input APIer.
• InputPointerSource API: Representerer et objekt som er registrert for å rapportere pekerinndata, og gir pekermarkør og inndatahendelsehåndtering for XAMLs SwapChainPanel API.
• Cursor API: Lar utviklere endre punktgrafikk for markøren.
• GestureRecognizer API: Lar utviklere gjenkjenne visse bevegelser som dra, hold og klikk når de får pekerinformasjon.

Viktige begrensninger

• Alle PointerPoint statiske fabrikkfunksjoner er fjernet: GetCurrentPoint, GetCurrentPointTransformed, Få mellompoengog GetIntermediatePointsTransformert.
• Windows App SDK støtter ikke henting PointerPoint objekter med peker-IDer. I stedet kan du bruke PointerPoint medlemsfunksjon GetTransformedPoint for å hente en transformert versjon av en eksisterende PointerPoint gjenstand. For mellompoeng kan du bruke PointEventArgs medlemsfunksjoner Få mellompoeng og Få TransformedIntermediatePoints.
• Direkte bruk av plattformens SDK API Windows.UI.Core.CoreDragOperation vil ikke fungere med WinUI-applikasjoner.
• PointerPoint egenskaper RawPosition og Kontakt RectRaw ble fjernet fordi de refererte til ikke-forutsagte verdier, som var de samme som normalverdiene i operativsystemet. Bruk Stilling og KontaktRect i stedet. Pekerprediksjon håndteres nå med Microsoft.UI.Input.PointerPredictor API-objekt.

Appens livssyklus

De fleste av App Lifecycle-funksjonene finnes allerede i UWP-plattformen, og har blitt brakt inn i Windows App SDK for bruk av skrivebordsapptyper, spesielt upakkede konsollapper, Win32-apper, Windows Forms-apper og WPF-apper. Windows App SDK-implementeringen av disse funksjonene kan ikke brukes i UWP-apper, siden det er tilsvarende funksjoner i selve UWP-plattformen.

Ikke-UWP-apper kan også pakkes inn i MSIX-pakker. Selv om disse appene kan bruke noen av Windows App SDK App Lifecycle-funksjoner, må de bruke manifest-tilnærmingen der dette er tilgjengelig. De kan for eksempel ikke bruke Windows App SDK Registrer ForXXXActivation APIer og må i stedet registrere seg for rik aktivering via manifestet.

Alle begrensningene for pakkede apper gjelder også for WinUI-apper, som er pakket, og det er flere hensyn som beskrevet nedenfor.

Viktige hensyn:

• Rik aktivering: GetActivatedEventArgs
  • Upakkede apper: Fullt brukbar.
  • Pakkede apper: Brukbar, men disse appene kan også bruke plattformen GetActivatedEventArgs. Merk at plattformen definerer Windows.ApplicationModel.AppInstance mens Windows App SDK definerer Microsoft.Windows.AppLifecycle.AppInstance. Og mens UWP-apper kan bruke ActivatedEventArgs klasser, som f.eks FileActivatedEventArgs og LaunchActivatedEventArgs, må apper som bruker Windows App SDK AppLifecycle-funksjonen bruke grensesnittene ikke klassene (f.eks. IFileActivatedEventArgs, ILaunchActivatedEventArgs, og så videre).
  • WinUi-apper: WinUIs App.OnLaunched får en Microsoft.UI.Xaml.LaunchActivatedEventArgs, mens plattformen GetActivatedEventArgs returnerer a Windows.ApplicationModel.IActivatedEventArgs, og WindowsAppSDK GetActivatedEventArgs returnerer a Microsoft.Windows.AppLifecycle.AppActivationArguments objekt som kan representere en plattform LaunchActivatedEventArgs.
  • For mer info, se Rik aktivering.
• Registrer/avregistrer deg for rik aktivering
  • Upakkede apper: Fullt brukbar.
  • Pakkede apper: Ikke brukbart bruk appens MSIX-manifest i stedet.
  • For mer info, se Rik aktivering.
• Enkelt-/Multi-instansering
  • Upakkede apper: Fullt brukbar.
  • Pakkede apper: Fullt brukbar.
  • WinUI-apper: Hvis en app ønsker å oppdage andre forekomster og omdirigere en aktivering, må den gjøre det så tidlig som mulig, og før initialisering av eventuelle vinduer osv. For å aktivere dette må appen definere DISABLE_XAML_GENERATED_MAIN, og skrive en egendefinert Main (C#) eller WinMain (C++) hvor den kan gjøre deteksjon og omdirigering.
  • RedirectActivationToAsync er et asynkront anrop, og du bør ikke vente på et asynkront anrop hvis appen din kjører i en STA. For Windows Forms- og C# WinUI-apper kan du om nødvendig erklære at Main er asynkron. For C++ WinUI- og C# WPF-apper kan du ikke erklære Main som asynkron, så i stedet må du flytte omdirigeringskallet til en annen tråd for å sikre at du ikke blokkerer STA.
  • For mer info, se App-instansering.
• Strøm-/statsvarsler
  • Upakkede apper: Fullt brukbar.
  • Pakkede apper: Fullt brukbar.
  • For mer info, se Strømstyring.

Kjent problem:

• Filtypetilknytninger koder feilaktig %1 til å være %251 når du angir verbbehandlerens kommandolinjemal, som krasjer upakkede Win32-apper. Du kan manuelt redigere registerverdien til %1 i stedet som en delvis løsning. Hvis målfilbanen har et mellomrom, vil den fortsatt mislykkes, og det er ingen løsning for det scenariet.
• Disse enkelt-/multi-instanseringsfeilene vil bli fikset i en kommende serviceoppdatering:
  • AppInstance-omdirigering fungerer ikke når den er kompilert for x86
  • Registrering av en nøkkel, avregistrering av den og omregistrering av den fører til at appen krasjer

WriteCore

DWriteCore er Windows App SDK-implementeringen av Direct, som er DirectX API for høykvalitets tekstgjengivelse, oppløsningsuavhengige disposisjonsfonter og full støtte for Unicode-tekst og layout. DWriteCore er en form for DirectWrite som kjører på versjoner av Windows ned til Windows 10, versjon 1809 (10.0; Bygg 17763), og åpner døren for at du kan bruke den på tvers av plattformer.

Egenskaper DWriteCore inneholder alle funksjonene til DirectWrite, med noen få unntak.

Viktige begrensninger

• DWriteCore inneholder ikke følgende DirectWrite-funksjoner:
  • Skrifter per økt
  • Sluttbrukerdefinerte tegn (EUDC) skrifter
  • Font-streaming APIer
• API-støtte for gjengivelse på lavt nivå er delvis.
• DWriteCore samvirker ikke med Direct2D, men du kan bruke IDWriteGlyphRunAnalysis og IDWriteBitmapRenderTarget.

MRT kjerne

MRT Core er en strømlinjeformet versjon av moderne Windows Ressursstyringssystem som distribueres som en del av Windows App SDK.

Viktige begrensninger

• I .NET-prosjekter indekseres ikke ressursfiler som er kopiert inn i prosjektmappen på F5 hvis appen allerede var bygget. Som en løsning kan du bygge appen på nytt. Se utgave 1503 for mer info.
• I .NET-prosjekter, når en ressursfil legges til prosjektet ved hjelp av Visual Studio-grensesnittet, kan det hende at filene ikke indekseres som standard. Se utgave 1786 for mer info. For å omgå dette problemet, vennligst fjern oppføringene nedenfor i CSPROJ-filen:

  XMLKopier

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

• For upakkede C++ WinUI-apper er ikke ressurs-URIen riktig bygget. For å omgå dette problemet, legg til følgende i vcxproj:

  XMLKopier

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

Utplassering

Nye funksjoner og oppdateringer

• Du kan automatisk initialisere Windows App SDK gjennom WindowsPackageType project egenskapen for å laste Windows App SDK runtime og kalle Windows App SDK APIer. Se Lag en WinUI 3-app for instruksjoner.
• Upakkede apper kan distribuere Windows App SDK ved å integreres i den frittstående Windows App SDK .exe installasjonsprogrammet inn i ditt eksisterende MSI eller oppsettprogram. For mer informasjon, se Windows App SDK-implementeringsveiledning for upakkede apper.
• Upakkede .NET-apper kan også bruke .NET-innpakning for bootstrapper API for å dynamisk ta en avhengighet av Windows App SDK-rammepakken under kjøretid. For mer informasjon om .NET-innpakningen, se .NET wrapper-bibliotek.
• Pakkede apper kan bruke distribusjons-API for å bekrefte og sikre at alle nødvendige pakker er installert på maskinen. For mer informasjon om hvordan distribusjons-APIet fungerer, se distribusjonsveiledning for pakkede apper.

Viktige begrensninger

• .NET-innpakningen for bootstrapper-API-en er kun ment for bruk av upakkede .NET-applikasjoner for å forenkle tilgangen til Windows App SDK.
• Bare MSIX-pakkede apper som er full tillit eller har pakkehåndtering begrenset funksjon har tillatelse til å bruke distribusjons-API for å installere hoved- og enkeltpakkeavhengighetene. Støtte for pakkede apper med delvis tillit kommer i senere utgivelser.
• Når F5 tester en x86-app som bruker DeploymentManager.Initialiser metoden på et x64-system, sørg for at x64-rammeverket først installeres ved å kjøre WindowsAppRuntimeInstall.exe. Ellers vil du møte en IKKE FUNNET feil på grunn av at Visual Studio ikke distribuerer x64-rammeverket, som vanligvis skjer gjennom Store-distribusjon eller sideinnlasting.

Andre begrensninger og kjente problemer

• Ingen støtte for noen CPU-byggkonfigurasjon: Når legge til Windows App SDK til en eksisterende .NET-applikasjon eller -komponent som støtter Enhver CPU, må du spesifisere ønsket arkitektur: x86, x64 or arm64.
• Oppgraderer fra .NET 5 til .NET 6: Når du oppgraderer i Visual Studio-grensesnittet, kan du støte på byggefeil. Som en løsning kan du manuelt oppdatere prosjektfilens TargetFrameworkPackage til følgende:

  XMLKopier

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

• C# Single-project MSIX app kompilerer ikke hvis C++ UWP Tools ikke er installert. Hvis du har et C# Single-project MSIX-prosjekt, må du installere C++ (v14x) Universal Windows-plattformverktøy valgfri komponent.
• Påfølgende språk VSIX klarer ikke å installere i Visual Studio 2019 når flere versjoner av Visual Studio 2019 er installert. Hvis du har flere versjoner av Visual Studio 2019 installert (f.eks. utgivelse og forhåndsvisning) og deretter installerer Windows App SDK VSIX for både C++ og C#, vil den andre installasjonen mislykkes. For å løse det, avinstaller Single-project MSIX Packaging Tools for Visual Studio 2019 etter førstespråket VSIX. Utsikt denne tilbakemeldingen for ytterligere informasjon om dette problemet.
• Hvis du ønsker å co_await på DispatcherQueue.TryEnqueue metoden, bruk deretter resume_foreground hjelpefunksjon i Windows Implementation Library (WIL):
  1. Legg til en referanse til Microsoft.Windows.ImplementationLibrary NuGet-pakke.
  2. Legg til #include <wil/cppwinrt_helpers.h> uttalelse til kodefilen din.
  3. Bruk wil::resume_foreground(your_dispatcher); til co_await resultatet.

Les mer og finn nedlastingslenkene hos Microsoft her..