Microsoft Windows App SDK 1.0 Stable julkaistu, ladattavissa (julkaisutiedot)

Useiden esikatseluversioiden jälkeen Microsoft on juuri julkaissut Windows App SDK 1.0.0 Stable -työkalusarjan, jonka avulla työpöytäsovellusten kehittäjät voivat rakentaa sovelluksia modernilla Windows-käyttöliittymällä, API:illa ja alustaominaisuuksilla.

Microsoft lisäsi tähän julkaisuun useita uusia ominaisuuksia Windows App SDK 0.8:sta ja stabiloi 1.0 Preview -julkaisujen ongelmia.

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

WindowsUI 3

WinUI 3 on Windows App SDK:n alkuperäinen käyttökokemus (UX) -kehys.

Uusia ominaisuuksia ja päivityksiä:

• Microsoft on lisännyt uusia ohjaimia (PipsPager, Expander, BreadcrumbBar) ja päivittänyt nykyiset säätimet vastaamaan uusimpia Windows-tyylejä WindowsUI 2.6.
• Yhden projektin MSIX-pakkausta tuetaan WinUI:ssa luomalla uusi sovellus käyttämällä "Tyhjä sovellus, pakattu…" -mallia.
• Microsoft tukee nyt WinUI 3 -sovellusten käyttöönottoa ilman MSIX-pakettia Windows-versioissa 1809 ja uudemmissa. Katso Luo pakkaamaton WinUI 3 -työpöytäsovellus lisätietoja.
• WinUI 3 -projektit voivat nyt asettaa kohdeversionsa Windows 10:een, versioon 1809. Aikaisemmin ne voitiin asettaa vain niin alhaiseksi kuin versio 1903.
• Sovelluksen sisäinen työkalupalkki, Hot Reload ja Live Visual Tree WinUI-pakattuille sovelluksille ovat tuettuja Visual Studio 2022 Preview 5:ssä ja GA:ssa.

Tärkeitä rajoituksia:

• Tunnettuja ongelmia varten sekä pakatut että pakkaamattomat WinUI-sovellukset:
  • Ajonaikainen virhe C++-sovelluksissa, jotka viittaavat C++:n Windows Runtime -komponenttiin: Voit ratkaista ongelman lisäämällä alla olevan kohteen Windows Runtime Componentin .vcxproj-ohjelman loppuun:

    XMLkopio

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

• Tunnettuja ongelmia varten WinUI-sovellukset, joissa on yhden projektin MSIX (Tyhjä sovellus, pakattu malli):
  • Puuttuva Package & Publish -valikkokohta, kunnes käynnistät Visual Studion uudelleen: Kun luot uuden sovelluksen yhden projektin MSIX:llä sekä Visual Studio 2019:ssä että Visual Studio 2022:ssa käyttämällä Tyhjä sovellus, pakattu (WinUI 3 in Desktop) -projektimallia, projektin julkaisukomento ei ilmesty valikkoon ennen kuin suljet sen. ja avaa Visual Studio uudelleen.
  • AC#-sovellus, jossa on yhden projektin MSIX, ei käänny ilman valinnaista C++ (v14x) Universal Windows Platform Tools -komponenttia asennettuna. Näytä Asenna kehittäjätyökalut lisätietoja.
  • Mahdollinen ajonaikainen virhe sovelluksessa, jossa on yhden projektin MSIX, joka kuluttaa viitatussa Windows Runtime Componentissa määritettyjä tyyppejä: Ratkaise lisäämällä manuaalisesti aktivoitavat luokkamerkinnät tiedostoon appxmanifest.xml.
    • Odotettu virhe C#-sovelluksissa on "COMException: Class not register (0x80040154 (REGDB_E_CLASSNOTREG)).
    • Odotettu virhe C++/WinRT-sovelluksissa on "winrt::hresult_class_not_registered".
• Tunnettuja ongelmia varten WinUI-sovellukset ilman MSIX-pakkausta (pakkaamattomat sovellukset):
  • Jotkut sovellusliittymät vaativat paketin identiteetin, eikä niitä tueta pakkaamattomissa sovelluksissa, kuten:
    • Sovelluksen tiedot
    • StorageFile.GetFileFromApplicationUriAsync
    • StorageFile.CreateStreamedFileFromUriAsync
    • ApiInformation (ei tuettu Windows 10:ssä)
    • Paketti. Nykyinen
    • Mikä tahansa API:ssa Windows.ApplicationModel.Resources nimiavaruus
    • Mikä tahansa API:ssa Microsoft.Windows.ApplicationModel.Resources nimiavaruus
• Tunnettuja ongelmia varten WinUI-sovellusten pakkaaminen ja käyttöönotto:
  • - Package komentoa ei tueta WinUI-sovelluksissa, joissa on yhden projektin MSIX (tyhjä sovellus, pakattu malli). Käytä sen sijaan Package & Publish komento luodaksesi MSIX-paketin.
  • NuGet-paketin luominen C#-luokan kirjastosta käyttämällä Pack komento, varmista aktiivinen Configuration is Release.
  • - Pack -komentoa ei tueta C++:n Windows Runtime Componentsissa NuGet-paketin luomiseksi.

Ikkunointi

Windows App SDK tarjoaa AppWindow luokka, joka kehittää aiemman helppokäyttöisen Windows.UI.WindowManagement.AppWindow-esikatseluluokan ja tuo sen kaikkien Windows-sovelluksien, mukaan lukien Win32, WPF ja WinForms, saataville.

Uudet ominaisuudet

• AppWindow on korkean tason ikkunointisovellusliittymä, joka mahdollistaa helppokäyttöiset ikkunointiskenaariot, jotka integroituvat hyvin Windowsin käyttökokemukseen ja muihin sovelluksiin. Edustaa korkean tason abstraktiota sovelluksen sisällön järjestelmähallinnasta. Tämä on säilö, jossa sisältöäsi isännöidään, ja se edustaa kokonaisuutta, jonka kanssa käyttäjät ovat vuorovaikutuksessa, kun he muuttavat sovelluksesi kokoa ja siirtävät sitä näytölle. Win32:n tunteville kehittäjille AppWindow voidaan pitää HWND:n korkean tason abstraktiona.
• Näyttöalue edustaa HMONITORin korkean tason abstraktiota, noudattaa samoja periaatteita kuin AppWindow.
• DisplayAreaWatcher avulla kehittäjä voi tarkkailla muutoksia näytön topologiassa ja luetella järjestelmässä tällä hetkellä määritetyt näyttöalueet.

panos

Nämä ovat syöttösovellusliittymiä, jotka tukevat WinUI:ta ja tarjoavat alemman tason API-pinnan kehittäjille edistyneemmän syöttövuorovaikutuksen saavuttamiseksi.

Uudet ominaisuudet

• Osoitinsovellusliittymät: PointerPoint, PointerPointPropertiesja PointEventArgs tukemaan osoitintapahtumatietojen hakua XAML-syöttörajapintojen avulla.
• InputPointerSource API: Edustaa objektia, joka on rekisteröity raportoimaan osoitinsyöttöä, ja tarjoaa osoitinkohdistimen ja syöttötapahtumien käsittelyn XAML:n SwapChainPanel API:lle.
• Kohdistimen API: Antaa kehittäjien muuttaa kohdistimen bittikartta.
• GestureRecognizer API: Antaa kehittäjien tunnistaa tietyt eleet, kuten vedä, pidä ja napsauta, kun heille annetaan osoitintiedot.

Tärkeitä rajoituksia

• Kaikki PointerPoint staattiset tehdastoiminnot on poistettu: Hanki CurrentPoint, Hanki CurrentPointTransformed, Hanki Intermediate Pointsja Hanki IntermediatePointsTransformed.
• Windows App SDK ei tue noutoa PointerPoint objektit osoitintunnuksilla. Sen sijaan voit käyttää PointerPoint jäsentoiminto HankiTransformedPoint noutaaksesi muunnetun version olemassa olevasta PointerPoint esine. Välipisteissä voit käyttää PointEventArgs jäsentoiminnot Hanki Intermediate Points ja HankiTransformedIntermediatePoints.
• Alustan SDK API:n suora käyttö Windows.UI.Core.CoreDragOperation ei toimi WinUI-sovellusten kanssa.
• PointerPoint ominaisuudet RawPosition ja Ota yhteyttäRectRaw poistettiin, koska ne viittasivat ei-ennustettuihin arvoihin, jotka olivat samat kuin käyttöjärjestelmän normaaliarvot. Käyttää asema ja Ota yhteyttäRect sen sijaan. Osoittimen ennustusta käsitellään nyt kanssa Microsoft.UI.Input.PointerPredictor API-objekti.

Sovelluksen elinkaari

Suurin osa App Lifecycle -ominaisuuksista on jo olemassa UWP-alustalla, ja ne on tuotu Windows App SDK:hen työpöytäsovellustyyppien, erityisesti pakkaamattomien konsolisovellusten, Win32-sovellusten, Windows Forms -sovellusten ja WPF-sovellusten, käyttöä varten. Näiden ominaisuuksien Windows App SDK -toteutusta ei voi käyttää UWP-sovelluksissa, koska itse UWP-alustassa on vastaavia ominaisuuksia.

Ei-UWP-sovelluksia voidaan myös pakata MSIX-paketteihin. Vaikka nämä sovellukset voivat käyttää joitain Windows App SDK:n App Lifecycle -ominaisuuksia, niiden on käytettävä manifestia, jos se on saatavilla. He eivät esimerkiksi voi käyttää Windows App SDK:ta Rekisteröidy XXXaktivointiin sovellusliittymiä, ja sen sijaan on rekisteröidyttävä rich-aktivointiin luettelon kautta.

Kaikki pakattuille sovelluksille asetetut rajoitukset koskevat myös WinUI-sovelluksia, jotka on pakattu, ja alla on kuvattu muita huomioita.

Tärkeitä näkökohtia:

• Rikas aktivointi: GetActivatedEventArgs
  • Pakkaamattomat sovellukset: Täysin käyttökelpoinen.
  • Pakatut sovellukset: Käyttökelpoinen, mutta nämä sovellukset voivat myös käyttää alustaa GetActivatedEventArgs. Huomaa, että alusta määrittää Windows.ApplicationModel.AppInstance kun taas Windows App SDK määrittelee Microsoft.Windows.AppLifecycle.AppInstance. Ja vaikka UWP-sovellukset voivat käyttää ActivatedEventArgs luokat, kuten FileActivatedEventArgs ja LaunchActivatedEventArgs, sovellusten, jotka käyttävät Windows App SDK AppLifecycle -ominaisuutta, on käytettävä rajapintoja, ei luokkia (esim. IFileActivatedEventArgs, ILaunchActivatedEventArgs, ja niin edelleen).
  • WinUi-sovellukset: WinUI:n App.OnLaunchedille annetaan a Microsoft.UI.Xaml.LaunchActivatedEventArgs, kun taas alusta GetActivatedEventArgs palauttaa a Windows.ApplicationModel.IActivatedEventArgsja WindowsAppSDK GetActivatedEventArgs palauttaa a Microsoft.Windows.AppLifecycle.AppActivationArguments objekti, joka voi edustaa alustaa LaunchActivatedEventArgs.
  • Katso lisätietoja Rikas aktivointi.
• Rekisteröidy/peruuta rekisteröinti monipuolista aktivointia varten
  • Pakkaamattomat sovellukset: Täysin käyttökelpoinen.
  • Pakatut sovellukset: Ei käytettävissä, käytä sen sijaan sovelluksen MSIX-luetteloa.
  • Katso lisätietoja Rikas aktivointi.
• Yksi-/Moni-instanssi
  • Pakkaamattomat sovellukset: Täysin käyttökelpoinen.
  • Pakatut sovellukset: Täysin käyttökelpoinen.
  • WinUI-sovellukset: Jos sovellus haluaa havaita muita esiintymiä ja ohjata aktivointi uudelleen, sen on tehtävä se mahdollisimman aikaisin ja ennen ikkunoiden alustamista jne. Tämän mahdollistamiseksi sovelluksen on määritettävä DISABLE_XAML_GENERATED_MAIN ja kirjoitettava mukautettu pää (C#) tai WinMain (C++), jossa se voi tehdä havaitsemisen ja uudelleenohjauksen.
  • RedirectActivationToAsync on asynkroninen puhelu, eikä sinun pidä odottaa asynkronista puhelua, jos sovelluksesi on käynnissä STA:ssa. Windows Forms- ja C# WinUI -sovelluksissa voit määrittää Main-toiminnon asynciseksi tarvittaessa. C++ WinUI- ja C# WPF-sovelluksissa et voi ilmoittaa Main-päätä asynkroniseksi, joten sen sijaan sinun on siirrettävä uudelleenohjauskutsu toiseen säikeeseen varmistaaksesi, että et estä STA:ta.
  • Katso lisätietoja Sovelluksen esiintyminen.
• Virta/tila-ilmoitukset
  • Pakkaamattomat sovellukset: Täysin käyttökelpoinen.
  • Pakatut sovellukset: Täysin käyttökelpoinen.
  • Katso lisätietoja Virranhallinta.

Tunnettu ongelma:

• Tiedostotyyppiliitokset koodaavat %1 virheellisesti muotoon %251 asetettaessa verbikäsittelijän komentorivimallia, mikä kaataa pakkaamattomat Win32-sovellukset. Voit muokata rekisterin arvoksi manuaalisesti %1 osittaisena ratkaisuna. Jos kohdetiedoston polussa on välilyönti, se epäonnistuu edelleen, eikä tälle skenaariolle ole ratkaisua.
• Nämä yhden tai usean esiintymisen virheet korjataan tulevassa huoltokorjauksessa:
  • AppInstance-uudelleenohjaus ei toimi, kun se on käännetty x86:lle
  • Avaimen rekisteröinti, sen rekisteröinnin poistaminen ja uudelleenrekisteröinti aiheuttaa sovelluksen kaatumisen

WriteCore

DWriteCore on Windows App SDK -toteutus DirectWrite, joka on DirectX-sovellusliittymä korkealaatuiseen tekstin renderöintiin, resoluutiosta riippumattomiin ääriviivafontteihin ja täydelliseen Unicode-tekstin ja -asettelun tukeen. DWriteCore on DirectWrite-muoto, joka toimii Windows-versioissa aina Windows 10 -versioon 1809 (10.0; Build 17763) asti ja avaa oven käyttöympäristöjen väliseen käyttöön.

Ominaisuudet DWriteCore sisältää kaikki DirectWrite-ominaisuudet muutamaa poikkeusta lukuun ottamatta.

Tärkeitä rajoituksia

• DWriteCore ei sisällä seuraavia DirectWrite-ominaisuuksia:
  • Istuntokohtaiset fontit
  • Loppukäyttäjän määrittämät kirjasimet (EUDC).
  • Font-streaming API:t
• Matalan tason renderöinnin API-tuki on osittainen.
• DWriteCore ei toimi Direct2D:n kanssa, mutta voit käyttää IDWriteGlyphRunAnalysis ja IDWriteBitmapRenderTarget.

MRT ydin

MRT Core on nykyaikaisen Windowsin virtaviivaistettu versio Resurssienhallintajärjestelmä joka on jaettu osana Windows App SDK:ta.

Tärkeitä rajoituksia

• .NET-projekteissa projektikansioon kopioituja resurssitiedostoja ei indeksoida F5:llä, jos sovellus on jo rakennettu. Ratkaisuna voit rakentaa sovelluksen uudelleen. Katso numero 1503 lisätietoja.
• Kun .NET-projekteissa resurssitiedosto lisätään projektiin Visual Studion käyttöliittymällä, tiedostoja ei välttämättä indeksoida oletusarvoisesti. Katso numero 1786 saadaksesi lisätietoja. Voit kiertää tämän ongelman poistamalla alla olevat merkinnät CSPROJ-tiedostosta:

  XMLkopio

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

• Pakkaamattomien C++ WinUI -sovellusten resurssin URI:tä ei ole rakennettu oikein. Voit kiertää tämän ongelman lisäämällä seuraavat tiedot vcxproj-ohjelmaan:

  XMLkopio

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

käyttöönoton

Uusia ominaisuuksia ja päivityksiä

• Voit alustaa Windows App SDK:n automaattisesti WindowsPackageType project -ominaisuutta ladataksesi Windows App SDK:n suoritusajan ja kutsuaksesi Windows App SDK:n sovellusliittymiä. Katso Luo WinUI 3 -sovellus ohjeita.
• Pakkaamattomat sovellukset voivat ottaa käyttöön Windows App SDK:n integroimalla erillisen Windows App SDK:n .exe asennusohjelma olemassa olevaan MSI- tai asennusohjelmaasi. Katso lisätietoja Windows App SDK:n käyttöönottoopas pakkaamattomille sovelluksille.
• Pakkaamattomat .NET-sovellukset voivat myös käyttää .NET-käärettä bootstrapper API ottaaksesi dynaamisesti riippuvuuden Windows App SDK -kehyspaketista ajon aikana. Lisätietoja .NET-kääreestä on kohdassa .NET-käärekirjasto.
• Pakatut sovellukset voivat käyttää käyttöönotto-API:tä varmistaakseen ja varmistaakseen, että kaikki vaaditut paketit on asennettu koneeseen. Lisätietoja käyttöönoton API:n toiminnasta on kohdassa paketoitujen sovellusten käyttöönottoopas.

Tärkeitä rajoituksia

• Bootstrapper API:n .NET-kääre on tarkoitettu vain pakkaamattomien .NET-sovellusten käyttöön Windows App SDK:n käytön yksinkertaistamiseksi.
• Vain MSIX-pakatut sovellukset, jotka ovat täysin luotettavia tai joilla on paketinhallinta rajoitetuilla ominaisuuksilla on lupa käyttää käyttöönottosovellusliittymää pää- ja yksittäispakettiriippuvuuksien asentamiseen. Tuki osittain luotettaville pakattuille sovelluksille on tulossa myöhemmissä julkaisuissa.
• Kun F5 testaa x86-sovellusta, joka käyttää DeploymentManager.Initialize -menetelmällä x64-järjestelmässä, varmista, että x64-kehys asennetaan ensin suorittamalla WindowsAppRuntimeInstall.exe. Muuten kohtaat a EI LÖYDETTY virhe, joka johtuu siitä, että Visual Studio ei ota käyttöön x64-kehystä, mikä tapahtuu tavallisesti Store-asennuksen tai sivulatauksen kautta.

Muut rajoitukset ja tunnetut ongelmat

• Ei tukea millekään CPU-koontikokoonpanolle: Kun Windows App SDK:n lisääminen olemassa olevaan .NET-sovellukseen tai -komponenttiin, joka tukee sitä Mikä tahansa CPU, sinun on määritettävä haluamasi arkkitehtuuri: x86, x64 or arm64.
• Päivitys .NET 5:stä .NET 6:een: Kun päivität Visual Studion käyttöliittymässä, saatat kohdata rakennusvirheitä. Kiertokeinona päivitä projektitiedostosi TargetFrameworkPackage manuaalisesti alla olevaan muotoon:

  XMLkopio

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

• C# yhden projektin MSIX-sovellus ei käännä, jos C++ UWP Tools -työkaluja ei ole asennettu. Jos sinulla on C# Single-project MSIX -projekti, sinun on asennettava C++ (v14x) Universal Windows Platform Tools valinnainen komponentti.
• Myöhempi kieli VSIX ei asennu Visual Studio 2019:ään, kun Visual Studio 2019:stä on asennettu useita versioita. Jos sinulla on asennettuna useita Visual Studio 2019 -versioita (esim. julkaisu ja esikatselu) ja asenna sitten Windows App SDK VSIX sekä C++:lle ja C#, toinen asennus epäonnistuu. Voit ratkaista ongelman poistamalla Visual Studio 2019:n yhden projektin MSIX Packaging Tools -ohjelmiston ensimmäisen kielen VSIX:n jälkeen. Näytä tämä palaute saadaksesi lisätietoja tästä ongelmasta.
• Jos haluat co_await på den DispatcherQueue.TryEnqueue menetelmää, käytä sitten resume_foreground aputoiminto Windows Implementation Library (WIL):
  1. Lisää viittaus Microsoft.Windows.ImplementationLibrary NuGet paketti.
  2. Lisää #include <wil/cppwinrt_helpers.h> lausunto kooditiedostoosi.
  3. Käyttää wil::resume_foreground(your_dispatcher); että co_await lopputulos.

Lue lisää ja etsi latauslinkit Microsoftilta tätä.