Microsoft Windows App SDK 1.0 Stable a fost lansat, disponibil pentru descărcare (Note de lansare)

După mai multe versiuni de previzualizare, Microsoft tocmai a lansat Windows App SDK 1.0.0 Stable, un set de instrumente care permite dezvoltatorilor de aplicații desktop să creeze aplicații cu o interfață de utilizare Windows, API-uri și caracteristici ale platformei moderne.

În această versiune, Microsoft a adăugat mai multe funcții noi din Windows App SDK 0.8 și a stabilizat problemele din versiunile 1.0 Preview.

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

WindowsUI 3

WinUI 3 este cadrul de experiență nativă a utilizatorului (UX) pentru Windows App SDK.

Funcții noi și actualizări:

• Microsoft a adăugat noi controale (PipsPager, Expander, BreadcrumbBar) și a actualizat controalele existente pentru a reflecta cele mai recente stiluri Windows de la WindowsUI 2.6.
• Ambalarea MSIX pentru un singur proiect este acceptată în WinUI prin crearea unei noi aplicații folosind șablonul „Aplicație goală, împachetat…”.
• Microsoft acceptă acum implementarea aplicațiilor WinUI 3 fără pachetul MSIX pe versiunile Windows 1809 și mai sus. Vă rugăm să vizualizați Creați o aplicație desktop neambalată WinUI 3 pentru informații suplimentare.
• Proiectele WinUI 3 își pot seta acum versiunea țintă până la Windows 10, versiunea 1809. Anterior, acestea puteau fi setate doar la versiunea 1903.
• Bara de instrumente în aplicație, Reîncărcare la cald și Arbore vizual în direct pentru aplicațiile WinUI sunt acceptate în Visual Studio 2022 Preview 5 și GA.

Limitări importante:

• Probleme cunoscute pentru ambele aplicații WinUI ambalate și neambalate:
  • Eroare de rulare în aplicațiile C++ care fac referire la o componentă Windows Runtime C++: Pentru a rezolva, adăugați ținta de mai jos la sfârșitul .vcxproj al componentei Windows Runtime:

    XMLCopiați

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

• Probleme cunoscute pentru Aplicații WinUI cu MSIX cu un singur proiect (Aplicație goală, șablon ambalat):
  • Elementul de meniu Pachet și Publicare lipsește până când reporniți Visual Studio: Când creați o aplicație nouă cu MSIX cu un singur proiect atât în ​​Visual Studio 2019, cât și în Visual Studio 2022, utilizând șablonul de proiect Blank App, Packaged (WinUI 3 în Desktop), comanda de publicare a proiectului nu apare în meniu până când nu închideți și redeschideți Visual Studio.
  • Aplicația AC# cu MSIX cu un singur proiect nu se va compila fără componenta opțională „C++ (v14x) Universal Windows Platform Tools” instalată. Vedere Instalați instrumente pentru dezvoltatori pentru informații suplimentare.
  • Potențială eroare de rulare într-o aplicație cu MSIX cu un singur proiect care consumă tipuri definite într-o componentă Windows Runtime la care se face referire: Pentru a rezolva, adăugați manual intrări de clasă activabile la appxmanifest.xml.
    • Eroarea așteptată în aplicațiile C# este „COMException: Class not registered (0x80040154 (REGDB_E_CLASSNOTREG)).
    • Eroarea așteptată în aplicațiile C++/WinRT este „winrt::hresult_class_not_registered”.
• Probleme cunoscute pentru Aplicații WinUI fără pachet MSIX (aplicații neambalate):
  • Unele API-uri necesită identitatea pachetului și nu sunt acceptate în aplicațiile neambalate, cum ar fi:
    • Application Data
    • StorageFile.GetFileFromApplicationUriAsync
    • StorageFile.CreateStreamedFileFromUriAsync
    • ApiInformation (nu este acceptat pe Windows 10)
    • Pachetul.Curentul
    • Orice API din Windows.ApplicationModel.Resources Spațiu de nume
    • Orice API din Microsoft.Windows.ApplicationModel.Resources Spațiu de nume
• Probleme cunoscute pentru ambalarea și implementarea aplicațiilor WinUI:
  •  Package comanda nu este acceptată în aplicațiile WinUI cu MSIX cu un singur proiect (aplicație goală, șablon pachet). În schimb, utilizați Package & Publish comandă pentru a crea un pachet MSIX.
  • Pentru a crea un pachet NuGet dintr-o bibliotecă de clasă C# cu Pack comanda, asigurați-l activ Configuration is Release.
  •  Pack comanda nu este acceptată în C++ Windows Runtime Components pentru a crea un pachet NuGet.

Înfășurarea

Windows App SDK oferă un AppWindow clasă care dezvoltă clasa anterioară de previzualizare Windows.UI.WindowManagement.AppWindow, ușor de utilizat, și o face disponibilă pentru toate aplicațiile Windows, inclusiv pentru Win32, WPF și WinForms.

Funcții noi

• AppWindow este un API de ferestre de nivel înalt care permite scenarii de ferestre ușor de utilizat, care se integrează bine cu experiența utilizatorului Windows și cu alte aplicații. Reprezintă o abstractizare la nivel înalt a unui container gestionat de sistem a conținutului unei aplicații. Acesta este containerul în care este găzduit conținutul dvs. și reprezintă entitatea cu care interacționează utilizatorii atunci când vă redimensionează și vă mută aplicația pe ecran. Pentru dezvoltatorii familiarizați cu Win32, AppWindow poate fi văzută ca o abstractizare la nivel înalt a HWND.
• Zona de afisare reprezintă o abstractizare la nivel înalt a unui HMONITOR, urmează aceleași principii ca și AppWindow.
• DisplayAreaWatcher permite unui dezvoltator să observe modificări în topologia de afișare și să enumere DisplayAreas definite în prezent în sistem.

Intrare

Acestea sunt API-urile de intrare care acceptă WinUI și oferă o suprafață API de nivel inferior pentru ca dezvoltatorii să realizeze interacțiuni de intrare mai avansate.

Funcții noi

• API-uri pointer: PointerPoint, PointerPointProperties, și PointEventArgs pentru a sprijini preluarea informațiilor despre evenimentele pointerului cu API-urile de intrare XAML.
• API-ul InputPointerSource: Reprezintă un obiect care este înregistrat pentru a raporta intrarea pointerului și oferă cursorului indicatorului și gestionarea evenimentelor de intrare pentru API-ul SwapChainPanel XAML.
• API-ul cursorului: Permite dezvoltatorilor să schimbe harta de biți a cursorului.
• API-ul GestureRecognizer: permite dezvoltatorilor să recunoască anumite gesturi, cum ar fi tragerea, menținerea apăsată și clic, atunci când li se oferă informații despre indicator.

Limitări importante

• TOATE PointerPoint funcțiile statice din fabrică au fost eliminate: GetCurrentPoint, GetCurrentPointTransformed, ObținePuncteIntermediare, și GetIntermediatePointsTransformed.
• Windows App SDK nu acceptă recuperarea PointerPoint obiecte cu ID-uri pointer. În schimb, puteți utiliza PointerPoint funcția de membru GetTransformedPoint pentru a prelua o versiune transformată a unui existent PointerPoint obiect. Pentru punctele intermediare, puteți utiliza PointEventArgs funcții de membru ObținePuncteIntermediare și GetTransformedIntermediatePoints.
• Utilizarea directă a API-ului SDK al platformei Windows.UI.Core.CoreDragOperation nu va funcționa cu aplicațiile WinUI.
• PointerPoint proprietăţi RawPosition și ContactațiRectRaw au fost eliminate deoarece se refereau la valori neprevăzute, care erau aceleași cu valorile normale din sistemul de operare. Utilizare Poziţie și ContactRect in schimb. Predicția pointerului este acum gestionată cu Microsoft.UI.Input.PointerPredictor obiect API.

Ciclul de viață al aplicației

Cele mai multe dintre funcțiile App Lifecycle există deja în platforma UWP și au fost aduse în Windows App SDK pentru a fi utilizate de tipurile de aplicații desktop, în special de aplicații Console neambalate, aplicații Win32, aplicații Windows Forms și aplicații WPF. Implementarea Windows App SDK a acestor caracteristici nu poate fi utilizată în aplicațiile UWP, deoarece există caracteristici echivalente în platforma UWP în sine.

Aplicațiile non-UWP pot fi, de asemenea, împachetate în pachete MSIX. Deși aceste aplicații pot folosi unele dintre caracteristicile Windows App SDK App Lifecycle, ele trebuie să utilizeze abordarea manifest acolo unde aceasta este disponibilă. De exemplu, aceștia nu pot utiliza SDK-ul pentru aplicații Windows Înregistrați-vă pentru XXXActivare API-uri și, în schimb, trebuie să se înregistreze pentru activarea bogată prin intermediul manifestului.

Toate constrângerile pentru aplicațiile împachetate se aplică și aplicațiilor WinUI, care sunt împachetate, și există considerații suplimentare, așa cum este descris mai jos.

Considerații importante:

• Activare bogată: GetActivatedEventArgs
  • Aplicații neambalate: Complet utilizabil.
  • Aplicații împachetate: Utilizabil, dar aceste aplicații pot folosi și platforma GetActivatedEventArgs. Rețineți că platforma definește Windows.ApplicationModel.AppInstance în timp ce Windows App SDK definește Microsoft.Windows.AppLifecycle.AppInstance. Și în timp ce aplicațiile UWP pot folosi ActivatedEventArgs clase, cum ar fi FileActivatedEventArgs și LaunchActivatedEventArgs, aplicațiile care utilizează caracteristica Windows App SDK AppLifecycle trebuie să utilizeze interfețele, nu clasele (de exemplu, IFileActivatedEventArgs, ILaunchActivatedEventArgs, si asa mai departe).
  • aplicații WinUi: WinUI's App.OnLaunched are a Microsoft.UI.Xaml.LaunchActivatedEventArgs, în timp ce platforma GetActivatedEventArgs returnează a Windows.ApplicationModel.IActivatedEventArgs, și WindowsAppSDK GetActivatedEventArgs returnează a Microsoft.Windows.AppLifecycle.AppActivationArguments obiect care poate reprezenta o platformă LaunchActivatedEventArgs.
  • Pentru mai multe informații, consultați Activare bogată.
• Înregistrați/Anulați înregistrarea pentru activare bogată
  • Aplicații neambalate: Complet utilizabil.
  • Aplicații împachetate: Nu se poate utiliza în schimb manifestul MSIX al aplicației.
  • Pentru mai multe informații, consultați Activare bogată.
• Unică/multi-instanță
  • Aplicații neambalate: Complet utilizabil.
  • Aplicații împachetate: Complet utilizabil.
  • aplicații WinUI: Dacă o aplicație dorește să detecteze alte instanțe și să redirecționeze o activare, trebuie să facă acest lucru cât mai devreme posibil și înainte de a inițializa orice fereastră etc. Pentru a activa acest lucru, aplicația trebuie să definească DISABLE_XAML_GENERATED_MAIN și să scrie un Main (C#) personalizat sau WinMain (C++) unde poate face detectarea și redirecționarea.
  • RedirectActivationToAsync este un apel asincron și nu ar trebui să așteptați un apel asincron dacă aplicația dvs. rulează într-un STA. Pentru aplicațiile Windows Forms și C# WinUI, puteți declara Principal ca fiind asincron, dacă este necesar. Pentru aplicațiile C++ WinUI și C# WPF, nu puteți declara Main ca fiind asincron, așa că trebuie să mutați apelul de redirecționare într-un alt fir pentru a vă asigura că nu blocați STA.
  • Pentru mai multe informații, consultați Instanțarea aplicației.
• Notificări de putere/stat
  • Aplicații neambalate: Complet utilizabil.
  • Aplicații împachetate: Complet utilizabil.
  • Pentru mai multe informații, consultați Gestionare a energiei.

Problema cunoscuta:

• Asociațiile de tip de fișier codifică incorect %1 pentru a fi %251 atunci când setați șablonul de linie de comandă al handler-ului Verb, care blochează aplicațiile Win32 neambalate. Puteți edita manual valoarea Registrului pentru a fi %1, ca o soluție parțială. Dacă calea fișierului țintă are un spațiu în ea, atunci va eșua și nu există o soluție pentru acel scenariu.
• Aceste erori cu o singură instanță/multi-instanță vor fi remediate într-un patch de service viitor:
  • Redirecționarea AppInstance nu funcționează atunci când este compilată pentru x86
  • Înregistrarea unei chei, anularea înregistrării acesteia și reînregistrarea acesteia provoacă blocarea aplicației

WriteCore

DWriteCore este implementarea Windows App SDK a DirectWrite, care este API-ul DirectX pentru redarea textului de înaltă calitate, fonturi de contur independente de rezoluție și suport complet pentru text și aspect Unicode. DWriteCore este o formă de DirectWrite care rulează pe versiuni de Windows până la Windows 10, versiunea 1809 (10.0; Build 17763) și vă deschide ușa pentru a o utiliza pe mai multe platforme.

DESCRIERE DWriteCore conține toate caracteristicile DirectWrite, cu câteva excepții.

Limitări importante

• DWriteCore nu conține următoarele caracteristici DirectWrite:
  • Fonturi pe sesiune
  • Fonturi cu caractere definite de utilizatorul final (EUDC).
  • API-uri pentru fluxul de fonturi
• Suportul API de randare la nivel scăzut este parțial.
• DWriteCore nu interoperează cu Direct2D, dar puteți utiliza IDWriteGlyphRunAnalysis și IDWriteBitmapRenderTarget.

MRT Core

MRT Core este o versiune simplificată a Windows-ului modern Sistem de management al resurselor care este distribuit ca parte a Windows App SDK.

Limitări importante

• În proiectele .NET, fișierele de resurse copiate-lipite în folderul proiectului nu sunt indexate pe F5 dacă aplicația a fost deja construită. Ca o soluție, reconstruiți aplicația. Vedea numărul 1503 pentru mai multe informaţii.
• În proiectele .NET, atunci când un fișier de resursă este adăugat la proiect folosind interfața de utilizare Visual Studio, este posibil ca fișierele să nu fie indexate în mod implicit. Vedea numărul 1786 pentru mai multe informatii. Pentru a rezolva această problemă, eliminați intrările de mai jos din fișierul CSPROJ:

  XMLCopiați

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

• Pentru aplicațiile C++ WinUI neambalate, URI-ul resursei nu este construit corect. Pentru a rezolva această problemă, adăugați următoarele în vcxproj:

  XMLCopiați

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

Implementare

Funcții noi și actualizări

• Puteți inițializa automat Windows App SDK prin intermediul WindowsPackageType project proprietate pentru a încărca Windows App SDK runtime și pentru a apela API-urile Windows App SDK. Vedea Creați o aplicație WinUI 3 pentru instrucțiuni.
• Aplicațiile neambalate pot implementa Windows App SDK prin integrarea în Windows App SDK autonom .exe instalator în programul dvs. MSI sau de configurare existent. Pentru mai multe informații, vezi Ghid de implementare Windows App SDK pentru aplicații neambalate.
• Aplicațiile .NET neambalate pot folosi, de asemenea, .NET wrapper pentru API-ul bootstrapper pentru a prelua în mod dinamic o dependență de pachetul cadru Windows App SDK în timpul execuției. Pentru mai multe informații despre wrapper-ul .NET, consultați Bibliotecă wrapper .NET.
• Aplicațiile împachetate pot folosi API-ul de implementare pentru a verifica și a se asigura că toate pachetele necesare sunt instalate pe computer. Pentru mai multe informații despre cum funcționează API-ul de implementare, consultați ghid de implementare pentru aplicațiile împachetate.

Limitări importante

• Wrapper-ul .NET pentru API-ul bootstrapper este destinat doar utilizării de către aplicațiile .NET neambalate pentru a simplifica accesul la Windows App SDK.
• Numai aplicațiile ambalate MSIX care au încredere deplină sau au managementul pachetelor Capacitatea restricționată are permisiunea de a utiliza API-ul de implementare pentru a instala dependențele pachetului principal și singleton. Suportul pentru aplicațiile împachetate cu încredere parțială va veni în versiunile ulterioare.
• Când F5 testează o aplicație x86 care utilizează DeploymentManager.Initialize pe un sistem x64, asigurați-vă că cadrul x64 este mai întâi instalat prin rularea programului WindowsAppRuntimeInstall.exe. În caz contrar, vei întâlni un NU A FOST GASIT eroare datorată faptului că Visual Studio nu implementează cadrul x64, care are loc în mod normal prin implementarea Store sau prin încărcare laterală.

Alte limitări și probleme cunoscute

• Nu există suport pentru configurația de construcție a CPU: Cand adăugarea Windows App SDK la o aplicație sau componentă .NET existentă care acceptă Orice CPU, trebuie să specificați arhitectura dorită: x86, x64 or arm64.
• Actualizarea de la .NET 5 la .NET 6: Când faceți upgrade în interfața de utilizare Visual Studio, este posibil să întâlniți erori de compilare. Ca o soluție, actualizați manual TargetFrameworkPackage al fișierului de proiect la următoarele:

  XMLCopiați

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

• Aplicația MSIX pentru un singur proiect C# nu se compila dacă instrumentele C++ UWP nu sunt instalate. Dacă aveți un proiect MSIX C# cu un singur proiect, atunci va trebui să instalați C++ (v14x) Instrumente universale ale platformei Windows componenta optionala.
• Limba ulterioară VSIX nu reușește să se instaleze în Visual Studio 2019 când sunt instalate mai multe versiuni ale Visual Studio 2019. Dacă aveți mai multe versiuni de Visual Studio 2019 instalate (de exemplu, Lansare și Previzualizare) și apoi instalați Windows App SDK VSIX pentru ambele C++ și C#, a doua instalare va eșua. Pentru a rezolva, dezinstalați Instrumentele de ambalare MSIX pentru un singur proiect pentru Visual Studio 2019 după prima limbă VSIX. Vedere acest feedback pentru informații suplimentare despre această problemă.
• Dacă doriţi să co_await pe DispatcherQueue.TryEnqueue metoda, apoi utilizați reluare_prim-plan funcția de ajutor în Biblioteca de implementare Windows (WIL):
  1. Adăugați o referință la Microsoft.Windows.ImplementationLibrary Pachetul NuGet.
  2. Adauga #include <wil/cppwinrt_helpers.h> declarație în fișierul dvs. de cod.
  3. Utilizare wil::resume_foreground(your_dispatcher); la co_await rezultatul.

Citiți mai multe și găsiți linkurile de descărcare la Microsoft aici.