Wydano stabilną wersję pakietu Microsoft Windows App SDK 1.0, można ją pobrać (uwagi do wydania)

Po kilku kompilacjach Preview firma Microsoft właśnie wydała Windows App SDK 1.0.0 Stable, zestaw narzędzi, który umożliwia programistom aplikacji komputerowych tworzenie aplikacji z nowoczesnym interfejsem użytkownika, interfejsami API i funkcjami platformy systemu Windows.

W tej wersji firma Microsoft dodała wiele nowych funkcji z pakietu Windows App SDK 0.8 i ustabilizowała problemy z wersji 1.0 Preview.

[lwptoc title=”WindowsAppSDK 1.0 Stable” szerokość=”30%” float=”right”]

WindowsUI 3

WinUI 3 to natywna struktura środowiska użytkownika (UX) dla zestawu SDK aplikacji systemu Windows.

Nowe funkcje i aktualizacje:

• Firma Microsoft dodała nowe kontrolki (PipsPager, Expander, BreadcrumbBar) i zaktualizowała istniejące kontrolki, aby odzwierciedlić najnowsze style systemu Windows z WindowsUI 2.6.
• Jednoprojektowe pakowanie MSIX jest obsługiwane w WinUI przez utworzenie nowej aplikacji przy użyciu szablonu „Puste aplikacje, spakowane…”.
• Firma Microsoft obsługuje teraz wdrażanie aplikacji WinUI 3 bez pakietów MSIX w systemie Windows w wersji 1809 i nowszych. Proszę zobaczyć Utwórz niespakowaną aplikację komputerową WinUI 3 W celu uzyskania dalszych informacji.
• Projekty WinUI 3 mogą teraz ustawić swoją docelową wersję na Windows 10, wersja 1809. Wcześniej mogły być ustawione tylko na wersję 1903.
• Pasek narzędzi w aplikacji, ponowne ładowanie na gorąco i dynamiczne drzewo wizualne dla aplikacji w pakiecie WinUI są obsługiwane w programie Visual Studio 2022 w wersji zapoznawczej 5 i GA.

Ważne ograniczenia:

• Znane problemy dla zarówno spakowane, jak i niespakowane aplikacje WinUI:
  • Błąd wykonania w aplikacjach C++, które odwołują się do składnika środowiska wykonawczego C++ systemu Windows: Aby rozwiązać ten problem, dodaj poniższy element docelowy na końcu pliku .vcxproj składnika środowiska wykonawczego systemu Windows:

    XMLSkopiuj

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

• Znane problemy dla Aplikacje WinUI z pojedynczym projektem MSIX (Pusta aplikacja, spakowany szablon):
  • Brakujący element menu Pakiet & Publikuj do momentu ponownego uruchomienia programu Visual Studio: Podczas tworzenia nowej aplikacji z pojedynczym projektem MSIX w programie Visual Studio 2019 i Visual Studio 2022 przy użyciu szablonu projektu Pusta aplikacja, pakiet (WinUI 3 na komputerze) polecenie opublikowania projektu nie pojawia się w menu, dopóki nie zamkniesz i ponownie otwórz program Visual Studio.
  • Aplikacja AC# z pojedynczym projektem MSIX nie skompiluje się bez zainstalowanego opcjonalnego składnika „C++ (v14x) Universal Windows Platform Tools”. Pogląd Zainstaluj narzędzia programistyczne W celu uzyskania dalszych informacji.
  • Potencjalny błąd czasu wykonywania w aplikacji z pojedynczym projektem MSIX, który wykorzystuje typy zdefiniowane w przywoływanym składniku środowiska wykonawczego systemu Windows: Aby rozwiązać problem, dodaj ręcznie aktywowane wpisy klas do pliku appxmanifest.xml.
    • Oczekiwany błąd w aplikacjach języka C# to „COMException: Klasa niezarejestrowana (0x80040154 (REGDB_E_CLASSNOTREG)).
    • Oczekiwany błąd w aplikacjach C++/WinRT to „winrt::hresult_class_not_registered”.
• Znane problemy dla Aplikacje WinUI bez pakietów MSIX (aplikacje nieopakowane):
  • Niektóre interfejsy API wymagają tożsamości pakietu i nie są obsługiwane w aplikacjach bez pakietów, na przykład:
    • Dane aplikacji
    • StorageFile. GetFileFromApplicationUriAsync
    • StorageFile.CreateStreamedFileFromUriAsync
    • Informacje o interfejsie API (nieobsługiwane w systemie Windows 10)
    • Pakiet.Aktualny
    • Dowolny interfejs API w Windows.ApplicationModel.Resources przestrzeń nazw
    • Dowolny interfejs API w Microsoft.Windows.ApplicationModel.Resources przestrzeń nazw
• Znane problemy dla pakowanie i wdrażanie aplikacji WinUI:
  • Połączenia Package Polecenie nie jest obsługiwane w aplikacjach WinUI z pojedynczym projektem MSIX (pusta aplikacja, spakowany szablon). Zamiast tego użyj Package & Publish polecenie, aby utworzyć pakiet MSIX.
  • Aby utworzyć pakiet NuGet z biblioteki klas C# za pomocą Pack polecenie, upewnij się, że aktywne Configuration is Release.
  • Połączenia Pack polecenie nie jest obsługiwane w C++ składnikach środowiska wykonawczego systemu Windows, aby utworzyć pakiet NuGet.

Okienkowanie

Windows App SDK zapewnia Okno aplikacji klasa, która ewoluuje poprzednią, łatwą w użyciu klasę Windows.UI.WindowManagement.AppWindow podglądu i udostępnia ją wszystkim aplikacjom systemu Windows, w tym Win32, WPF i WinForms.

Nowe funkcje

• Okno aplikacji to wysokopoziomowy interfejs API do obsługi okien, który umożliwia łatwe w użyciu scenariusze okienek, które dobrze integrują się z interfejsem użytkownika systemu Windows i innymi aplikacjami. Reprezentuje abstrakcję wysokiego poziomu kontenera zarządzanego przez system zawartości aplikacji. Jest to kontener, w którym przechowywane są Twoje treści, i reprezentuje jednostkę, z którą użytkownicy wchodzą w interakcję, gdy zmieniają rozmiar i przenoszą Twoją aplikację na ekranie. Dla programistów zaznajomionych z Win32, AppWindow może być postrzegany jako abstrakcja wysokiego poziomu HWND.
• Obszar wyświetlania reprezentuje abstrakcję wysokiego poziomu HMONITOR, działa zgodnie z tymi samymi zasadami, co AppWindow.
• Obserwator obszaru wyświetlania umożliwia programiście obserwowanie zmian w topologii wyświetlania i wyliczanie obszarów DisplayAreas aktualnie zdefiniowanych w systemie.

Wkład

Są to wejściowe interfejsy API, które obsługują WinUI i zapewniają deweloperom powierzchnię interfejsu API niższego poziomu w celu uzyskania bardziej zaawansowanych interakcji wejściowych.

Nowe funkcje

• Wskaźniki API: WskaźnikPunkt, Właściwości punktu wskaźnika, PointEventArgs do obsługi pobierania informacji o zdarzeniach wskaźnika za pomocą wejściowych interfejsów API XAML.
• Interfejs API InputPointerSource: reprezentuje obiekt, który jest zarejestrowany do wprowadzania wskaźnika raportu i zapewnia kursor wskaźnika i obsługę zdarzeń wejściowych dla interfejsu API SwapChainPanel XAML.
• Kursor API: Umożliwia programistom zmianę mapy bitowej kursora.
• Interfejs API rozpoznawania gestów: umożliwia programistom rozpoznawanie określonych gestów, takich jak przeciąganie, przytrzymywanie i klikanie, gdy otrzymują informacje o wskaźniku.

Ważne ograniczenia

• Wszystkie kategorie WskaźnikPunkt usunięto statyczne funkcje fabryczne: PobierzBieżącyPunkt, GetCurrentPointTransformed, Zdobądź punkty pośrednie, GetIntermediatePointsTransformed.
• Windows App SDK nie obsługuje pobierania WskaźnikPunkt obiekty z identyfikatorami wskaźników. Zamiast tego możesz użyć WskaźnikPunkt funkcja członka PobierzTransformedPoint odzyskać przekształconą wersję istniejącego WskaźnikPunkt obiekt. W przypadku punktów pośrednich możesz użyć PointEventArgs funkcje składowe Zdobądź punkty pośrednie i GetTransformedIntermediatePoints.
• Bezpośrednie korzystanie z platformy SDK API Operacja Windows.UI.Core.CoreDrag nie będzie działać z aplikacjami WinUI.
• WskaźnikPunkt niska zabudowa Pozycja surowa i KontaktRectRaw zostały usunięte, ponieważ odnosiły się do nieprzewidywanych wartości, które były takie same jak normalne wartości w systemie operacyjnym. Posługiwać się Pozycja i KontaktRect zamiast. Przewidywanie wskaźnika jest teraz obsługiwane przez Microsoft.UI.Input.PointerPredictor Obiekt API.

Cykl życia aplikacji

Większość funkcji cyklu życia aplikacji istnieje już na platformie platformy UWP i została przeniesiona do zestawu Windows App SDK do użytku przez typy aplikacji klasycznych, w szczególności niespakowane aplikacje konsolowe, aplikacje Win32, aplikacje Windows Forms i aplikacje WPF. Implementacja zestawu SDK aplikacji systemu Windows tych funkcji nie może być używana w aplikacjach platformy UWP, ponieważ istnieją równoważne funkcje na samej platformie platformy UWP.

Aplikacje inne niż platformy UWP można również pakować w pakiety MSIX. Chociaż te aplikacje mogą korzystać z niektórych funkcji cyklu życia aplikacji Windows App SDK, muszą używać podejścia manifestu, jeśli jest to dostępne. Na przykład nie mogą korzystać z zestawu SDK aplikacji dla systemu Windows Zarejestruj się dlaXXXaktywacji interfejsów API i zamiast tego należy zarejestrować się w celu aktywacji rozszerzonej za pośrednictwem manifestu.

Wszystkie ograniczenia dotyczące aplikacji w pakietach dotyczą również aplikacji WinUI, które są w pakietach, i istnieją dodatkowe kwestie opisane poniżej.

Ważne uwagi:

• Bogata aktywacja: GetActivatedEventArgs
  • Rozpakowane aplikacje: W pełni użyteczny.
  • Pakiety aplikacji: Użyteczne, ale te aplikacje mogą również korzystać z platformy GetActivatedEventArgs. Zauważ, że platforma definiuje Windows.ApplicationModel.AppInstance podczas gdy Windows App SDK definiuje Cykl życia aplikacji Microsoft.Windows.AppInstance. I chociaż aplikacje UWP mogą korzystać z ActivatedEventArgs zajęcia, takie jak FileActivatedEventArgs i LaunchActivatedEventArgs, aplikacje korzystające z funkcji Windows App SDK AppLifecycle muszą używać interfejsów, a nie klas (np. IFileActivatedEventArgs, ILaunchActivatedEventArgs, i tak dalej).
  • Aplikacje WinUi: WinUI App.OnLaunched otrzymuje Microsoft.UI.Xaml.LaunchActivatedEventArgs, natomiast platforma GetActivatedEventArgs zwraca a Windows.ApplicationModel.IActivatedEventArgsi WindowsAppSDK GetActivatedEventArgs zwraca a Microsoft.Windows.AppLifecycle.Argumenty aktywacji aplikacji obiekt, który może reprezentować platformę LaunchActivatedEventArgs.
  • Aby uzyskać więcej informacji, zobacz Bogata aktywacja.
• Zarejestruj się/wyrejestruj w celu uzyskania bogatej aktywacji
  • Rozpakowane aplikacje: W pełni użyteczny.
  • Pakiety aplikacji: Nie można używać zamiast tego manifestu MSIX aplikacji.
  • Aby uzyskać więcej informacji, zobacz Bogata aktywacja.
• Pojedyncze/wieloinstancyjne
  • Rozpakowane aplikacje: W pełni użyteczny.
  • Pakiety aplikacji: W pełni użyteczny.
  • Aplikacje WinUI: Jeśli aplikacja chce wykryć inne instancje i przekierować aktywację, musi to zrobić tak szybko, jak to możliwe, przed zainicjowaniem jakichkolwiek okien itp. Aby to umożliwić, aplikacja musi zdefiniować DISABLE_XAML_GENERATED_MAIN i napisać niestandardowy Main (C#) lub WinMain (C++), gdzie może wykonać detekcję i przekierowanie.
  • Przekieruj aktywację na Async jest wywołaniem asynchronicznym i nie należy czekać na wywołanie asynchroniczne, jeśli aplikacja działa w STA. W przypadku aplikacji Windows Forms i C# WinUI można zadeklarować Main jako asynchroniczny, jeśli to konieczne. W przypadku aplikacji C++ WinUI i C# WPF nie można zadeklarować Main jako asynchronicznego, więc zamiast tego należy przenieść wywołanie przekierowania do innego wątku, aby upewnić się, że nie blokujesz STA.
  • Aby uzyskać więcej informacji, zobacz Wystąpienie aplikacji.
• Powiadomienia dotyczące zasilania/stanu
  • Rozpakowane aplikacje: W pełni użyteczny.
  • Pakiety aplikacji: W pełni użyteczny.
  • Aby uzyskać więcej informacji, zobacz Zarządzanie energią.

Znana kwestia:

• Skojarzenia typu pliku niepoprawnie kodują %1 na %251 podczas ustawiania szablonu wiersza poleceń modułu obsługi czasownika, co powoduje awarię niespakowanych aplikacji Win32. Zamiast tego można ręcznie zmienić wartość rejestru na %1 jako częściowe obejście. Jeśli ścieżka pliku docelowego zawiera spację, nadal nie powiedzie się i nie ma obejścia tego scenariusza.
• Te błędy dotyczące pojedynczych/wielu wystąpień zostaną naprawione w nadchodzącej łatce serwisowej:
  • Przekierowanie AppInstance nie działa po skompilowaniu dla x86
  • Zarejestrowanie klucza, wyrejestrowanie go i ponowna rejestracja powoduje awarię aplikacji

WriteCore

DWriteCore to implementacja Windows App SDK firmy Bezpośredni zapis, czyli interfejs API DirectX zapewniający wysokiej jakości renderowanie tekstu, czcionki konturowe niezależne od rozdzielczości oraz pełną obsługę tekstu i układu Unicode. DWriteCore to forma DirectWrite, która działa w wersjach systemu Windows aż do Windows 10, wersja 1809 (10.0; kompilacja 17763) i otwiera drzwi do korzystania z niej na wielu platformach.

Korzyści DWriteCore zawiera wszystkie funkcje DirectWrite, z kilkoma wyjątkami.

Ważne ograniczenia

• DWriteCore nie zawiera następujących funkcji DirectWrite:
  • Czcionki na sesję
  • Czcionki znaku zdefiniowanego przez użytkownika końcowego (EUDC)
  • Interfejsy API do strumieniowego przesyłania czcionek
• Obsługa interfejsu API renderowania niskiego poziomu jest częściowa.
• DWriteCore nie współpracuje z Direct2D, ale możesz użyć IDWriteGlyphRunAnaliza i IDWriteBitmapRenderTarget.

Rdzeń MRT

MRT Core to uproszczona wersja nowoczesnego systemu Windows System Zarządzania Zasobami dystrybuowany jako część zestawu Windows App SDK.

Ważne ograniczenia

• W projektach .NET pliki zasobów wklejone do folderu projektu nie są indeksowane na klawiszu F5, jeśli aplikacja została już skompilowana. Jako obejście, odbuduj aplikację. Widzieć wydanie 1503 więcej informacji.
• W projektach .NET, gdy plik zasobów jest dodawany do projektu przy użyciu interfejsu użytkownika programu Visual Studio, pliki mogą nie być indeksowane domyślnie. Widzieć wydanie 1786 po więcej informacji. Aby obejść ten problem, usuń poniższe wpisy w pliku CSPROJ:

  XMLSkopiuj

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

• W przypadku niespakowanych aplikacji C++ WinUI identyfikator URI zasobu nie jest poprawnie skompilowany. Aby obejść ten problem, dodaj następujące elementy w vcxproj:

  XMLSkopiuj

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

Rozlokowanie

Nowe funkcje i aktualizacje

• Możesz automatycznie zainicjować Windows App SDK za pomocą WindowsPackageType project Właściwość, aby załadować środowisko uruchomieniowe Windows App SDK i wywołać interfejsy API Windows App SDK. Widzieć Utwórz aplikację WinUI 3 po instrukcje.
• Niespakowane aplikacje mogą wdrażać pakiet SDK aplikacji systemu Windows, integrując się z samodzielnym pakietem SDK aplikacji systemu Windows .exe instalatora do istniejącego MSI lub programu instalacyjnego. Aby uzyskać więcej informacji, zobacz Przewodnik wdrażania Windows App SDK dla aplikacji bez pakietów.
• Rozpakowane aplikacje .NET mogą również używać otoki .NET dla ładujący API do dynamicznego przejmowania zależności od pakietu platformy Windows App SDK w czasie wykonywania. Aby uzyskać więcej informacji o opakowaniu .NET, zobacz Biblioteka opakowująca .NET.
• Aplikacje w pakietach mogą używać interfejsu API wdrażania do weryfikacji i upewniania się, że wszystkie wymagane pakiety są zainstalowane na komputerze. Aby uzyskać więcej informacji na temat działania interfejsu API wdrażania, zobacz przewodnik wdrażania aplikacji w pakietach.

Ważne ograniczenia

• Otoka platformy .NET dla interfejsu API ładowania początkowego jest przeznaczona tylko do użytku przez niespakowane aplikacje .NET w celu uproszczenia dostępu do zestawu SDK aplikacji systemu Windows.
• Tylko aplikacje w pakiecie MSIX, które są w pełni zaufane lub mają Zarządzanie pakietami ograniczone możliwości mają uprawnienia do korzystania z interfejsu API wdrażania do instalowania zależności pakietu głównego i pojedynczego. Wsparcie dla aplikacji w pakiecie z częściowym zaufaniem pojawi się w późniejszych wersjach.
• Gdy F5 testuje aplikację x86, która używa DeploymentManager.Initialize w systemie x64, upewnij się, że platforma x64 została najpierw zainstalowana, uruchamiając WindowsAppRuntimeInstall.exe. W przeciwnym razie napotkasz NIE ZNALEZIONO błąd, ponieważ program Visual Studio nie wdraża platformy x64, co zwykle występuje podczas wdrażania sklepu lub ładowania bocznego.

Inne ograniczenia i znane problemy

• Brak wsparcia dla dowolnej konfiguracji kompilacji procesora: Gdy dodanie pakietu SDK aplikacji Windows do istniejącej aplikacji lub komponentu .NET, który obsługuje Dowolny procesor, musisz określić żądaną architekturę: x86, x64 or arm64.
• Aktualizacja z .NET 5 do .NET 6: podczas uaktualniania w interfejsie użytkownika programu Visual Studio mogą wystąpić błędy kompilacji. Jako obejście, ręcznie zaktualizuj TargetFrameworkPackage pliku projektu do poniższego:

  XMLSkopiuj

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

• C# aplikacja MSIX dla pojedynczego projektu nie kompiluje się, jeśli nie zainstalowano narzędzi platformy UWP języka C++. Jeśli masz projekt MSIX z pojedynczym projektem w języku C#, musisz zainstalować C++ (v14x) Uniwersalne narzędzia platformy Windows składnik opcjonalny.
• Nie można zainstalować kolejnego języka VSIX w programie Visual Studio 2019, gdy zainstalowano wiele wersji programu Visual Studio 2019. Jeśli masz zainstalowanych wiele wersji programu Visual Studio 2019 (np. Release i Preview), a następnie zainstaluj zestaw SDK aplikacji Windows VSIX dla obu C++ i C#, druga instalacja zakończy się niepowodzeniem. Aby rozwiązać problem, odinstaluj narzędzia do pakowania pojedynczego projektu MSIX dla programu Visual Studio 2019 po pierwszym języku VSIX. Pogląd ta opinia aby uzyskać dodatkowe informacje na temat tego problemu.
• Jeśli chcesz co_await na DispatcherQueue.TryEnqueue metody, a następnie użyj wznowić_pierwszy plan funkcja pomocnicza w Biblioteka implementacji systemu Windows (WIL):
  1. Dodaj odniesienie do Biblioteka Microsoft.Windows.Implementation Pakiet NuGet.
  2. Dodaj #include <wil/cppwinrt_helpers.h> oświadczenie do pliku kodu.
  3. Zastosowanie wil::resume_foreground(your_dispatcher); do co_await wynik.

Przeczytaj więcej i znajdź łącza do pobierania w witrynie Microsoft tutaj.