Microsoft Windows App SDK 1.0 Stable uitgebracht, beschikbaar om te downloaden (Release-opmerkingen)

Home » #Herposten

Pictogram voor leestijd 12 minuut. lezen

Kalender pictogram Bijgewerkt op

by Surur Davids 

bijgewerkt

deel dit artikel

Lezers helpen MSpoweruser ondersteunen. We kunnen een commissie krijgen als u via onze links koopt. Tooltip-pictogram

Lees onze openbaarmakingspagina om erachter te komen hoe u MSPoweruser kunt helpen het redactieteam te ondersteunen Lees meer

winUI

Na verschillende Preview-builds heeft Microsoft zojuist Windows App SDK 1.0.0 Stable uitgebracht, een toolkit waarmee ontwikkelaars van desktop-apps apps kunnen bouwen met een moderne Windows-gebruikersinterface, API's en platformfuncties.

In deze release heeft Microsoft meerdere nieuwe functies van Windows App SDK 0.8 toegevoegd en problemen gestabiliseerd uit 1.0 Preview-releases.

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

WindowsUI 3

WinUI 3 is het native user experience (UX) framework voor Windows App SDK.

Nieuwe functies en updates:

  • Microsoft heeft nieuwe besturingselementen toegevoegd (PipsPager, Expander, BreadcrumbBar) en bestaande besturingselementen bijgewerkt om de nieuwste Windows-stijlen van WindowsUI 2.6.
  • MSIX-verpakking voor één project wordt ondersteund in WinUI door een nieuwe toepassing te maken met behulp van de sjabloon "Blanco App, Packaged...".
  • Microsoft ondersteunt nu de implementatie van WinUI 3-apps zonder MSIX-verpakking op Windows-versies 1809 en hoger. Bekijk a.u.b. Maak een WinUI 3 onverpakte desktop-app voor meer informatie.
  • WinUI 3-projecten kunnen nu hun doelversie instellen op Windows 10, versie 1809. Voorheen konden ze alleen zo laag worden ingesteld als versie 1903.
  • In-app-werkbalk, Hot Reload en Live Visual Tree voor WinUI-pakketapps worden ondersteund in Visual Studio 2022 Preview 5 en GA.

Belangrijke beperkingen:

  • Bekende problemen voor zowel verpakte als onverpakte WinUI-toepassingen:
    • Runtime-fout in C++ apps die verwijzen naar een C++ Windows Runtime Component: Om dit op te lossen, voegt u het onderstaande doel toe aan het einde van de .vcxproj van de Windows Runtime Component:

      XML

      <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>
  • Bekende problemen voor WinUI-toepassingen met MSIX voor één project (Lege app, verpakt sjabloon):
    • Ontbrekend menu-item Pakket en publiceren totdat u Visual Studio opnieuw start: Wanneer u een nieuwe app maakt met Single-project MSIX in zowel Visual Studio 2019 als Visual Studio 2022 met behulp van de projectsjabloon Blank App, Packaged (WinUI 3 in Desktop), verschijnt de opdracht om het project te publiceren pas in het menu als u sluit en open Visual Studio opnieuw.
    • AC#-app met MSIX met één project kan niet worden gecompileerd zonder dat de optionele component "C++ (v14x) Universal Windows Platform Tools" is geïnstalleerd. Visie Ontwikkelaarstools installeren voor meer informatie.
    • Mogelijke runtime-fout in een app met MSIX voor één project die typen gebruikt die zijn gedefinieerd in een Windows Runtime-component waarnaar wordt verwezen: Om op te lossen, handmatig toevoegen activeerbare klasse-items naar appxmanifest.xml.
      • De verwachte fout in C#-toepassingen is "COMException: klasse niet geregistreerd (0x80040154 (REGDB_E_CLASSNOTREG)).
      • De verwachte fout in C++/WinRT-toepassingen is "winrt::hresult_class_not_registered".
  • Bekende problemen voor WinUI-applicaties zonder MSIX-verpakking (uitgepakte apps):
  • Bekende problemen voor WinUI-applicaties inpakken en implementeren:
    • De Package opdracht wordt niet ondersteund in WinUI-apps met MSIX met één project (lege app, verpakte sjabloon). Gebruik in plaats daarvan de Package & Publish commando om een ​​MSIX-pakket te maken.
    • Een NuGet-pakket maken vanuit een C#-klassenbibliotheek met de Pack commando, zorg ervoor dat de actieve Configuration is Release.
    • De Pack opdracht wordt niet ondersteund in C++ Windows Runtime Components om een ​​NuGet-pakket te maken.

windowing

De Windows App SDK biedt een AppWindow class die de vorige gebruiksvriendelijke Windows.UI.WindowManagement.AppWindow-previewklasse evolueert en beschikbaar maakt voor alle Windows-apps, inclusief Win32, WPF en WinForms.

Nieuwe mogelijkheden

  • AppWindow is een venster-API op hoog niveau die gebruiksvriendelijke vensterscenario's mogelijk maakt die goed integreert met de Windows-gebruikerservaring en met andere apps. Vertegenwoordigt een abstractie op hoog niveau van een door het systeem beheerde container van de inhoud van een app. Dit is de container waarin uw inhoud wordt gehost en vertegenwoordigt de entiteit waarmee gebruikers communiceren wanneer ze het formaat van uw app wijzigen en uw app op het scherm verplaatsen. Voor ontwikkelaars die bekend zijn met Win32, kan de AppWindow worden gezien als een abstractie op hoog niveau van de HWND.
  • Weergavegebied vertegenwoordigt een abstractie op hoog niveau van een HMONITOR, volgt dezelfde principes als AppWindow.
  • Geef AreaWatcher weer stelt een ontwikkelaar in staat om veranderingen in de weergavetopologie te observeren en DisplayAreas op te sommen die momenteel in het systeem zijn gedefinieerd.

Invoer

Dit zijn de invoer-API's die WinUI ondersteunen en die ontwikkelaars een lager API-oppervlak bieden om geavanceerdere invoerinteracties te realiseren.

Nieuwe mogelijkheden

  • Pointer-API's: PointerPunt, PointerPointEigenschappen en PuntEventArgs ter ondersteuning van het ophalen van pointer-gebeurtenisinformatie met XAML-invoer-API's.
  • InputPointerSource-API: Vertegenwoordigt een object dat is geregistreerd om aanwijzerinvoer te rapporteren, en biedt aanwijzercursor en invoergebeurtenisafhandeling voor XAML's SwapChainPanel API.
  • Cursor-API: Hiermee kunnen ontwikkelaars de cursorbitmap wijzigen.
  • GestureRecognizer-API: Hiermee kunnen ontwikkelaars bepaalde gebaren herkennen, zoals slepen, vasthouden en klikken wanneer ze aanwijzerinformatie krijgen.

Belangrijke beperkingen

  • Alles PointerPunt statische fabrieksfuncties zijn verwijderd: GetCurrentPoint, GetCurrentPointGetransformeerd, GetIntermediatePunten en GetIntermediatePointsGetransformeerd.
  • De Windows App SDK ondersteunt het ophalen niet PointerPunt objecten met aanwijzer-ID's. In plaats daarvan kunt u de PointerPunt lid functie GetTransformedPoint om een ​​getransformeerde versie van een bestaande op te halen PointerPunt object. Voor tussenliggende punten kunt u de PuntEventArgs ledenfuncties GetIntermediatePunten en GetTransformedTussenliggende Punten.
  • Direct gebruik van het platform SDK API Windows.UI.Core.CoreDragOperation werkt niet met WinUI-toepassingen.
  • PointerPunt vastgoed RawPositie en Neem contact op metRectRaw werden verwijderd omdat ze verwezen naar niet-voorspelde waarden, die hetzelfde waren als de normale waarden in het besturingssysteem. Gebruiken Positie en ContactRect in plaats van. Aanwijzervoorspelling wordt nu afgehandeld met de Microsoft.UI.Input.PointerPredictor API-object.

App-levenscyclus

De meeste App Lifecycle-functies bestaan ​​al in het UWP-platform en zijn in de Windows App SDK opgenomen voor gebruik door typen desktop-apps, met name onverpakte console-apps, Win32-apps, Windows Forms-apps en WPF-apps. De Windows App SDK-implementatie van deze functies kan niet worden gebruikt in UWP-apps, omdat er gelijkwaardige functies zijn in het UWP-platform zelf.

 belangrijk

Als u aan een UWP-app werkt, raadpleegt u: de UWP-migratierichtlijnen voor meer informatie over het migreren van uw app naar Windows App SDK.

Niet-UWP-apps kunnen ook worden verpakt in MSIX-pakketten. Hoewel deze apps enkele van de Windows App SDK App Lifecycle-functies kunnen gebruiken, moeten ze de manifest-aanpak gebruiken waar deze beschikbaar is. Ze kunnen bijvoorbeeld de Windows App SDK niet gebruiken RegistrerenForXXXActivation API's en moeten zich in plaats daarvan registreren voor uitgebreide activering via het manifest.

Alle beperkingen voor verpakte apps zijn ook van toepassing op WinUI-apps, die zijn verpakt, en er zijn aanvullende overwegingen zoals hieronder beschreven.

Belangrijke overwegingen:

  • Rijke activatie: GetActivatedEventArgs
  • Registreren/Afmelden voor uitgebreide activering
    • Uitgepakte apps: Volledig bruikbaar.
    • Verpakte apps: Niet bruikbaar, gebruik in plaats daarvan het MSIX-manifest van de app.
    • Zie voor meer informatie Rijke activatie.
  • Enkele/multi-instance
    • Uitgepakte apps: Volledig bruikbaar.
    • Verpakte apps: Volledig bruikbaar.
    • WinUI-apps: als een app andere instanties wil detecteren en een activering wil omleiden, moet hij dit zo vroeg mogelijk doen, en voordat vensters worden geïnitialiseerd, enz. Om dit in te schakelen, moet de app DISABLE_XAML_GENERATED_MAIN definiëren en een aangepaste Main (C#) of WinMain (C++) waar het de detectie en omleiding kan doen.
    • RedirectActivationToAsync is een asynchrone aanroep en u moet niet wachten op een asynchrone aanroep als uw app in een STA wordt uitgevoerd. Voor Windows Forms- en C# WinUI-apps kunt u indien nodig Main als async declareren. Voor C++ WinUI- en C# WPF-apps kunt u Main niet als async declareren, dus in plaats daarvan moet u de omleidingsaanroep naar een andere thread verplaatsen om ervoor te zorgen dat u de STA niet blokkeert.
    • Zie voor meer informatie App-instanties.
  • Power/Status-meldingen
    • Uitgepakte apps: Volledig bruikbaar.
    • Verpakte apps: Volledig bruikbaar.
    • Zie voor meer informatie Energiebeheer.

Bekend probleem:

  • Bestandstype-associaties coderen %1 onjuist als %251 bij het instellen van de opdrachtregelsjabloon van de werkwoordhandler, waardoor onverpakte Win32-apps crashen. U kunt in plaats daarvan als gedeeltelijke tijdelijke oplossing de registerwaarde handmatig wijzigen in %1. Als het doelbestandspad een spatie bevat, mislukt het nog steeds en is er geen oplossing voor dat scenario.
  • Deze bugs met één of meerdere instanties worden opgelost in een aanstaande onderhoudspatch:
    • AppInstance-omleiding werkt niet wanneer gecompileerd voor x86
    • Door een sleutel te registreren, de registratie ongedaan te maken en opnieuw te registreren, loopt de app vast

SchrijfKern

DWriteCore is de Windows App SDK-implementatie van Directschrijven, de DirectX API voor tekstweergave van hoge kwaliteit, resolutie-onafhankelijke contourlettertypen en volledige ondersteuning voor Unicode-tekst en lay-out. DWriteCore is een vorm van DirectWrite die draait op versies van Windows tot Windows 10, versie 1809 (10.0; build 17763) en opent de deur voor u om het platformonafhankelijk te gebruiken.

Voordelen DWriteCore bevat alle functies van DirectWrite, op een paar uitzonderingen na.

Belangrijke beperkingen

  • DWriteCore bevat niet de volgende DirectWrite-functies:
    • Lettertypen per sessie
    • Door de eindgebruiker gedefinieerde lettertekens (EUDC) lettertypen
    • Api's voor het streamen van lettertypen
  • Ondersteuning voor API-weergave op laag niveau is gedeeltelijk.
  • DWriteCore werkt niet samen met Direct2D, maar u kunt IDWriteGlyphRunAnalyse en IDWriteBitmapRenderTarget.

MRT-kern

MRT Core is een gestroomlijnde versie van het moderne Windows Resource Management System dat wordt gedistribueerd als onderdeel van de Windows App SDK.

Belangrijke beperkingen

  • In .NET-projecten worden bronbestanden die in de projectmap zijn gekopieerd en geplakt, niet geïndexeerd op F5 als de app al is gebouwd. Herbouw de app als tijdelijke oplossing. Zien kwestie 1503 voor meer info.
  • Wanneer in .NET-projecten een bronbestand aan het project wordt toegevoegd met behulp van de gebruikersinterface van Visual Studio, worden de bestanden mogelijk niet standaard geïndexeerd. Zien kwestie 1786 voor meer informatie. Om dit probleem te omzeilen, verwijdert u de onderstaande vermeldingen in het CSPROJ-bestand:

    XML

    <ItemGroup>
    <Content Remove="<image file name>" />
</ItemGroup>
<ItemGroup>
    <PRIResource Remove="<resw file name>" />
</ItemGroup>
  • Voor onverpakte C++ WinUI-apps is de resource-URI niet correct gebouwd. Om dit probleem te omzeilen, voegt u het volgende toe aan de vcxproj:

    XML

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

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

Deployment

Nieuwe functies en updates

  • U kunt de Windows App SDK automatisch initialiseren via de WindowsPackageType project eigenschap om de Windows App SDK-runtime te laden en de Windows App SDK-API's aan te roepen. Zien Een WinUI 3-app maken voor instructies.
  • Uitgepakte apps kunnen Windows App SDK implementeren door te integreren in de zelfstandige Windows App SDK .exe installer in uw bestaande MSI- of installatieprogramma. Voor meer info, zie Implementatiehandleiding voor Windows App SDK voor onverpakte apps.
  • Niet-verpakte .NET-apps kunnen ook .NET-wrapper gebruiken voor de bootstrapper-API om tijdens runtime dynamisch afhankelijk te worden van het Windows App SDK-frameworkpakket. Voor meer informatie over de .NET-wrapper, zie .NET-wrapperbibliotheek.
  • Verpakte apps kunnen de implementatie-API gebruiken om te controleren en ervoor te zorgen dat alle vereiste pakketten op de computer zijn geïnstalleerd. Voor meer informatie over hoe de implementatie-API werkt, zie de: implementatiehandleiding voor verpakte apps.

Belangrijke beperkingen

  • De .NET-wrapper voor de bootstrapper-API is alleen bedoeld voor gebruik door onverpakte .NET-toepassingen om de toegang tot de Windows App SDK te vereenvoudigen.
  • Alleen MSIX-pakket-apps die volledig vertrouwd zijn of de pakketbeheer beperkte mogelijkheden hebben de toestemming om de implementatie-API te gebruiken om de hoofd- en singleton-pakketafhankelijkheden te installeren. Ondersteuning voor verpakte apps met gedeeltelijk vertrouwen komt in latere releases.
  • Wanneer F5 een x86-app test die gebruikmaakt van de DeploymentManager.Initialiseren methode op een x64-systeem, zorg ervoor dat het x64-framework eerst wordt geïnstalleerd door de WindowsAppRuntimeInstall.exe. Anders kom je een NIET GEVONDEN fout doordat Visual Studio het x64-framework niet implementeert, wat normaal gesproken gebeurt via Store-implementatie of sideloading.

Andere beperkingen en bekende problemen

  • Geen ondersteuning voor elke CPU-buildconfiguratie: Wanneer de Windows App SDK toevoegen naar een bestaande .NET-toepassing of -component die ondersteuning biedt voor Elke CPU, moet u de gewenste architectuur opgeven: x86, x64 or arm64.
  • Upgraden van .NET 5 naar .NET 6: Bij het upgraden in de gebruikersinterface van Visual Studio kunt u buildfouten tegenkomen. Als tijdelijke oplossing kunt u het TargetFrameworkPackage van uw projectbestand handmatig bijwerken naar het onderstaande:

    XML

        <TargetFramework>net6.0-windows10.0.19041.0</TargetFramework>
  • C# MSIX-app voor één project compileert niet als C++ UWP Tools niet zijn geïnstalleerd. Als je een C# Single-project MSIX-project hebt, dan moet je de C++ (v14x) Universele Windows Platform Tools optioneel onderdeel.
  • Volgende taal VSIX kan niet worden geïnstalleerd in Visual Studio 2019 wanneer meerdere versies van Visual Studio 2019 zijn geïnstalleerd. Als u meerdere versies van Visual Studio 2019 hebt geïnstalleerd (bijv. Release en Preview) en installeer vervolgens de Windows App SDK VSIX voor beide C++ en C#, zal de tweede installatie mislukken. Om dit op te lossen, verwijdert u de MSIX Packaging Tools voor één project voor Visual Studio 2019 na de eerste taal VSIX. Visie deze feedback voor meer informatie over dit probleem.
  • Als u wilt co_await op de DispatcherQueue.TryEnqueue methode, gebruik dan de cv_foreground helperfunctie in de Windows Implementatie Bibliotheek (WIL):
    1. Voeg een verwijzing toe naar Microsoft.Windows.Implementatiebibliotheek NuGet-pakket.
    2. Voeg de #include <wil/cppwinrt_helpers.h> statement naar uw codebestand.
    3. Te gebruiken wil::resume_foreground(your_dispatcher); naar co_await het resultaat.

Lees meer en vind de downloadlinks op Microsoft hier.

Meer over de onderwerpen: SDK voor Windows-app 1.0.0, winui 3

Surur Davids

Surur Davids Schild

Smartphone-expert

Surur Davids is de oprichter van WMPoweruser, wat later MSPoweruser.com werd. Hij is een smartphone-expert met meer dan tien jaar ervaring.

Laat een reactie achter

Uw e-mailadres wordt niet gepubliceerd. Verplichte velden zijn gemarkeerd *