Microsoft Windows App SDK 1.0 Stable, доступний для завантаження (примітки до випуску)

Після кількох збірок попереднього перегляду Microsoft щойно випустила Windows App SDK 1.0.0 Stable, набір інструментів, який дає змогу розробникам настільних додатків створювати програми з сучасним інтерфейсом Windows, API та функціями платформи.

У цьому випуску Microsoft додала кілька нових функцій з Windows App SDK 0.8 і стабілізувала проблеми з версії 1.0 Preview.

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

WinUI 3

WinUI 3 — це базова платформа для роботи з користувачами (UX) для Windows App SDK.

Нові функції та оновлення:

• Корпорація Майкрософт додала нові елементи керування (PipsPager, Expander, BreadcrumbBar) та оновила наявні елементи керування, щоб відображати останні стилі Windows від WinUI 2.6.
• Пакування MSIX одного проекту підтримується в WinUI шляхом створення нової програми за допомогою шаблону «Пустий додаток, упакований…».
• Тепер Microsoft підтримує розгортання додатків WinUI 3 без упаковки MSIX у Windows версії 1809 і вище. Будь ласка, перегляньте Створіть розпакований настільний додаток WinUI 3 Для отримання додаткової інформації.
• Проекти WinUI 3 тепер можуть встановлювати цільову версію до Windows 10 версії 1809. Раніше їх можна було встановити лише до версії 1903.
• У програмі Visual Studio 2022 Preview 5 і GA підтримуються панель інструментів у програмі, гаряче перезавантаження та Live Visual Tree для пакетних програм WinUI.

Важливі обмеження:

• Відомі проблеми для як запаковані, так і неупаковані програми WinUI:
  • Помилка під час виконання в програмах C++, які посилаються на компонент C++ Windows Runtime: Щоб вирішити проблему, додайте ціль нижче в кінець .vcxproj компонента Windows Runtime:

    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>
    

• Відомі проблеми для Програми WinUI з одним проектом MSIX (Пустий додаток, упакований шаблон):
  • Відсутній пункт меню Package & Publish, доки ви не перезапустите Visual Studio: Під час створення нової програми з однопроектним MSIX як у Visual Studio 2019, так і в Visual Studio 2022 за допомогою шаблону проекту «Пуста програма, упакований» (WinUI 3 на робочому столі), команда для публікації проекту не з’являється в меню, доки ви не закриєте і знову відкрийте Visual Studio.
  • Програма AC# з MSIX для одного проекту не буде компілюватися без встановленого додаткового компонента «C++ (v14x) Universal Windows Platform Tools». Переглянути Встановіть інструменти розробника Для отримання додаткової інформації.
  • Потенційна помилка під час виконання програми з однопроектним MSIX, який використовує типи, визначені в компоненті Windows Runtime, на який посилаються: Щоб вирішити, додайте вручну активовані записи класів до appxmanifest.xml.
    • Очікувана помилка в програмах C#: «COMException: Клас не зареєстровано (0x80040154 (REGDB_E_CLASSNOTREG)).
    • Очікувана помилка в програмах C++/WinRT – «winrt::hresult_class_not_registered».
• Відомі проблеми для Програми WinUI без MSIX-упаковки (розпаковані програми):
  • Деякі API вимагають ідентифікації пакета і не підтримуються в розпакованих програмах, наприклад:
    • ApplicationData
    • StorageFile.GetFileFromApplicationUriAsync
    • StorageFile.CreateStreamedFileFromUriAsync
    • ApiInformation (не підтримується в Windows 10)
    • Пакет. Поточний
    • Будь-який API в Windows.ApplicationModel.Resources простору імен
    • Будь-який API в Microsoft.Windows.ApplicationModel.Resources простору імен
• Відомі проблеми для пакування та розгортання додатків WinUI:
  • Команда Package Команда не підтримується в програмах WinUI з одним проектом MSIX (пуста програма, упакований шаблон). Замість цього використовуйте Package & Publish команду для створення пакету MSIX.
  • Щоб створити пакет NuGet з бібліотеки класів C# за допомогою Pack команду, забезпечити активну Configuration is Release.
  • Команда Pack Команда не підтримується в C++ Windows Runtime Components для створення пакета NuGet.

Віконний

Windows App SDK надає AppWindow клас, який розвиває попередній простий у використанні клас попереднього перегляду Windows.UI.WindowManagement.AppWindow і робить його доступним для всіх програм Windows, включаючи Win32, WPF і WinForms.

Нові можливості

• AppWindow — це високорівневий віконний API, який дозволяє створювати прості у використанні сценарії вікон, які добре інтегруються з досвідом користувача Windows та іншими програмами. Являє високорівневу абстракцію керованого системою контейнера вмісту програми. Це контейнер, у якому розміщено ваш вміст, і являє собою об’єкт, з яким взаємодіють користувачі, коли змінюють розмір і переміщують вашу програму на екрані. Для розробників, знайомих з Win32, AppWindow можна розглядати як високорівневу абстракцію HWND.
• DisplayArea представляє високорівневу абстракцію HMONITOR, дотримуючись тих же принципів, що і AppWindow.
• DisplayAreaWatcher дозволяє розробнику спостерігати за змінами в топології відображення та перераховувати DisplayAreas, які наразі визначені в системі.

вхід

Це API введення, які підтримують WinUI і надають розробникам поверхню API нижчого рівня для досягнення більш розширених взаємодій введення.

Нові можливості

• API покажчика: PointerPoint, Властивості PointerPoint та  PointerEventArgs для підтримки отримання інформації про події вказівника за допомогою API введення XAML.
• API InputPointerSource: Представляє об’єкт, зареєстрований для введення вказівника звіту, і забезпечує обробку курсора вказівника та подій введення для API SwapChainPanel XAML.
• API курсора: дозволяє розробникам змінювати растрове зображення курсора.
• API GestureRecognizer: дозволяє розробникам розпізнавати певні жести, такі як перетягування, утримання та клацання, коли надається інформація про вказівник.

Важливі обмеження

• ВСІ PointerPoint статичні заводські функції видалено: GetCurrentPoint, GetCurrentPointTransformed, Отримайте IntermediatePoints та  GetIntermediatePointsTransformed.
• Windows App SDK не підтримує отримання PointerPoint об'єкти з ідентифікаторами покажчиків. Замість цього можна використовувати PointerPoint членська функція GetTransformedPoint щоб отримати трансформовану версію існуючої PointerPoint об'єкт. Для проміжних точок можна використовувати PointerEventArgs членські функції Отримайте IntermediatePoints та  GetTransformedIntermediatePoints.
• Безпосереднє використання API платформи SDK Windows.UI.Core.CoreDragOperation не працюватиме з додатками WinUI.
• PointerPoint властивості RawPosition та  Зв'яжіться з RectRaw були вилучені, оскільки вони посилалися на непередбачувані значення, які були такими ж, як і нормальні значення в ОС. Використовуйте становище та  Зв'яжіться з Rect замість цього. Передбачення покажчика тепер обробляється за допомогою Microsoft.UI.Input.PointerPredictor Об’єкт API.

Життєвий цикл програми

Більшість функцій життєвого циклу додатків уже існують на платформі UWP і були введені в Windows App SDK для використання типами настільних програм, особливо неупакованими консольними додатками, додатками Win32, додатками Windows Forms і програмами WPF. Реалізація цих функцій Windows App SDK не може використовуватися в програмах UWP, оскільки в самій платформі UWP є еквівалентні функції.

Програми, які не є UWP, також можна запакувати в пакети MSIX. Хоча ці програми можуть використовувати деякі функції Windows App SDK App Lifecycle, вони повинні використовувати підхід маніфесту, якщо він доступний. Наприклад, вони не можуть використовувати пакет Windows App SDK Реєстрація для XXXActivation API, і замість цього потрібно зареєструватися для активації розширеного доступу через маніфест.

Усі обмеження для пакетних програм також застосовуються до програм WinUI, які упаковані, і є додаткові міркування, описані нижче.

Важливі міркування:

• Розширена активація: GetActivatedEventArgs
  • Розпаковані програми: Повністю можна використовувати.
  • Запаковані програми: можна використовувати, але ці програми також можуть використовувати платформу GetActivatedEventArgs. Зауважте, що платформа визначає Windows.ApplicationModel.AppInstance тоді як Windows App SDK визначає Microsoft.Windows.AppLifecycle.AppInstance. І хоча додатки UWP можуть використовувати ActivatedEventArgs класи, наприклад FileActivatedEventArgs та  LaunchActivatedEventArgs, програми, які використовують функцію Windows App SDK AppLifecycle, повинні використовувати інтерфейси, а не класи (наприклад, IFileActivatedEventArgs, ILaunchActivatedEventArgs, і так далі).
  • Програми WinUi: WinUI App.OnLaunched отримує a Microsoft.UI.Xaml.LaunchActivatedEventArgs, тоді як платформа GetActivatedEventArgs повертає a Windows.ApplicationModel.IActivatedEventArgs, і WindowsAppSDK GetActivatedEventArgs повертає a Microsoft.Windows.AppLifecycle.AppActivationArguments об'єкт, який може представляти платформу LaunchActivatedEventArgs.
  • Докладніше див Багата активація.
• Зареєструвати/Скасувати реєстрацію для розширеної активації
  • Розпаковані програми: Повністю можна використовувати.
  • Запаковані програми: Не можна використовувати замість цього маніфест MSIX програми.
  • Докладніше див Багата активація.
• Один/багато екземплярів
  • Розпаковані програми: Повністю можна використовувати.
  • Запаковані програми: Повністю можна використовувати.
  • Програми WinUI: Якщо програма хоче виявити інші екземпляри та переспрямувати активацію, вона має зробити це якомога раніше, перш ніж ініціалізувати будь-які вікна тощо. Щоб увімкнути це, програма має визначити DISABLE_XAML_GENERATED_MAIN та написати спеціальний основний (C#) або WinMain (C++), де він може виконувати виявлення та перенаправлення.
  • RedirectActivationToAsync є асинхронним викликом, і вам не слід чекати на асинхронний виклик, якщо ваша програма працює в STA. Для програм Windows Forms і C# WinUI ви можете оголосити Main асинхронним, якщо це необхідно. Для програм C++ WinUI і C# WPF ви не можете оголосити Main асинхронним, тому замість цього вам потрібно перемістити виклик переспрямування в інший потік, щоб переконатися, що ви не блокуєте STA.
  • Докладніше див Інстанція програми.
• Сповіщення про живлення/стан
  • Розпаковані програми: Повністю можна використовувати.
  • Запаковані програми: Повністю можна використовувати.
  • Докладніше див управління енергоспоживанням.

Відома проблема:

• Асоціації типу файлу неправильно кодують %1 як %251 під час налаштування шаблону командного рядка обробника дієслова, що призводить до аварійного завершення роботи розпакованих програм Win32. Ви можете вручну змінити значення реєстру на %1 як частковий обхідний шлях. Якщо шлях цільового файлу містить пробіл, він все одно не вийде, і для цього сценарію немає обхідного шляху.
• Ці помилки з одним або кількома екземплярами будуть виправлені в наступному виправленні обслуговування:
  • Перенаправлення AppInstance не працює під час компіляції для x86
  • Реєстрація ключа, скасування його реєстрації та повторна реєстрація призводять до збою програми

DWriteCore

DWriteCore — це реалізація Windows App SDK DirectWrite, який є DirectX API для високоякісного відтворення тексту, незалежних від роздільної здатності контурних шрифтів і повної підтримки тексту та макета Unicode. DWriteCore — це форма DirectWrite, яка працює у версіях Windows аж до Windows 10 версії 1809 (10.0; збірка 17763) і відкриває двері для використання міжплатформно.

риси DWriteCore містить усі функції DirectWrite, за деякими винятками.

Важливі обмеження

• DWriteCore не містить таких функцій DirectWrite:
  • Шрифти за сеанс
  • Шрифти, визначені кінцевим користувачем (EUDC).
  • API потокової передачі шрифтів
• Підтримка API відтворення низького рівня є частковою.
• DWriteCore не взаємодіє з Direct2D, але ви можете використовувати IDWriteGlyphRunAnalysis та  IDWriteBitmapRenderTarget.

Ядро MRT

MRT Core — це оптимізована версія сучасної Windows Система управління ресурсами який поширюється як частина Windows App SDK.

Важливі обмеження

• У проектах .NET файли ресурсів, скопійовані в папку проекту, не індексуються за допомогою F5, якщо програма вже була створена. Як обхідний шлях перебудуйте програму. Подивитися випуск 1503 Додаткова інформація.
• У проектах .NET, коли файл ресурсу додається до проекту за допомогою інтерфейсу Visual Studio, файли можуть не індексуватися за замовчуванням. Подивитися випуск 1786 для отримання додаткової інформації. Щоб обійти цю проблему, видаліть наведені нижче записи у файлі CSPROJ:

  XMLСкопіювати

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

• Для неупакованих програм C++ WinUI URI ресурсу створено неправильно. Щоб обійти цю проблему, додайте наступне до vcxproj:

  XMLСкопіювати

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

розгортання

Нові функції та оновлення

• Ви можете автоматично ініціалізувати Windows App SDK за допомогою WindowsPackageType project властивість для завантаження середовища виконання Windows App SDK і виклику API для Windows App SDK. Подивитися Створіть програму WinUI 3 для інструкцій.
• Неупаковані програми можуть розгортати Windows App SDK шляхом інтеграції в автономний Windows App SDK .exe інсталятора у наявну програму MSI або установку. Для отримання додаткової інформації див Посібник із розгортання пакета SDK для програм Windows для неупакованих програм.
• Неупаковані програми .NET також можуть використовувати оболонку .NET для API завантажувача щоб динамічно залежати від пакета платформи Windows App SDK під час виконання. Додаткову інформацію про обгортку .NET див Бібліотека обгорток .NET.
• Упаковані програми можуть використовувати API розгортання, щоб перевірити та переконатися, що всі необхідні пакети встановлені на машині. Додаткову інформацію про те, як працює API розгортання, див посібник із розгортання пакетних програм.

Важливі обмеження

• Обгортка .NET для API завантажувача призначена лише для використання неупакованими програмами .NET для спрощення доступу до Windows App SDK.
• Лише запаковані програми MSIX, яким повністю довіряють або мають управління пакетами обмежені можливості мають дозвіл використовувати API розгортання для встановлення залежностей основного та одного пакета. Підтримка пакетних додатків із частковою довірою з’явиться в наступних випусках.
• Під час F5 тестування програми x86, яка використовує DeploymentManager.Initialize методу в системі x64, переконайтеся, що фреймворк x64 спочатку встановлено, запустивши файл WindowsAppRuntimeInstall.exe. Інакше ви зіткнетеся з a НЕ ЗНАЙДЕНО помилка через те, що Visual Studio не розгортає фреймворк x64, що зазвичай відбувається через розгортання Store або побічне завантаження.

Інші обмеження та відомі проблеми

• Немає підтримки будь-якої конфігурації збірки ЦП: Коли додавання пакета SDK для додатків Windows до наявної програми або компонента .NET, який підтримує Будь-який процесор, ви повинні вказати потрібну архітектуру: x86, x64 or arm64.
• Оновлення з .NET 5 до .NET 6: Під час оновлення в інтерфейсі Visual Studio ви можете зіткнутися з помилками збірки. Як обхідний шлях, вручну оновіть TargetFrameworkPackage файлу вашого проекту до наступного:

  XMLСкопіювати

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

• Програма MSIX для окремого проекту C# не компілюється, якщо не інстальовано інструменти C++ UWP. Якщо у вас є проект MSIX з одним проектом C#, вам потрібно буде встановити файл C++ (v14x) Універсальні інструменти платформи Windows необов'язковий компонент.
• Наступну мову VSIX не вдається встановити в Visual Studio 2019, якщо встановлено кілька версій Visual Studio 2019. Якщо у вас встановлено декілька версій Visual Studio 2019 (наприклад, випуск і попередній перегляд), а потім інсталюйте пакет Windows App SDK VSIX для обох C++ та  C#, друга інсталяція не вийде. Щоб вирішити проблему, видаліть одиночний проект MSIX Packaging Tools для Visual Studio 2019 після першої мови VSIX. Переглянути цей відгук для отримання додаткової інформації з цього питання.
• Якщо ви хочете co_await на DispatcherQueue.TryEnqueue метод, потім скористайтеся резюме_переднього плану допоміжна функція в Бібліотека впровадження Windows (WIL):
  1. Додайте посилання на Microsoft.Windows.ImplementationLibrary Пакет NuGet.
  2. Додати #include <wil/cppwinrt_helpers.h> оператор до вашого кодового файлу.
  3. Скористайтесь wil::resume_foreground(your_dispatcher); до co_await результат.

Дізнайтеся більше та знайдіть посилання для завантаження в Microsoft тут.