Выпущена стабильная версия Microsoft Windows App SDK 1.0, доступная для загрузки (примечания к выпуску)

После нескольких предварительных сборок Microsoft только что выпустила Windows App SDK 1.0.0 Stable — набор инструментов, который позволяет разработчикам настольных приложений создавать приложения с современным пользовательским интерфейсом Windows, API-интерфейсами и функциями платформы.

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

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

WinUI 3

WinUI 3 — это собственная платформа взаимодействия с пользователем (UX) для Windows App SDK.

Новые функции и обновления:

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

Важные ограничения:

• Известные проблемы для как упакованные, так и неупакованные приложения WinUI:
  • Ошибка времени выполнения в приложениях C++, которые ссылаются на компонент среды выполнения Windows C++: Чтобы решить эту проблему, добавьте указанную ниже цель в конец файла .vcxproj компонента среды выполнения Windows:

    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: Чтобы решить, вручную добавьте активируемые записи класса в appxmanifest.xml.
    • Ожидаемая ошибка в приложениях C#: «COMException: класс не зарегистрирован (0x80040154 (REGDB_E_CLASSNOTREG)).
    • Ожидаемая ошибка в приложениях C++/WinRT — «winrt::hresult_class_not_registered».
• Известные проблемы для Приложения WinUI без MSIX-упаковки (неупакованные приложения):
  • Для некоторых API требуется идентификация пакета, и они не поддерживаются в неупакованных приложениях, например:
    • Данные приложений
    • StorageFile.GetFileFromApplicationUriAsync
    • StorageFile.CreateStreamedFileFromUriAsync
    • АпиИнформация (не поддерживается в 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 для создания пакета NuGet.

Окно

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

Новые функции

• Окно приложения — это высокоуровневый API управления окнами, который позволяет создавать простые в использовании сценарии работы с окнами, которые хорошо интегрируются с пользовательским интерфейсом Windows и другими приложениями. Представляет высокоуровневую абстракцию управляемого системой контейнера содержимого приложения. Это контейнер, в котором размещается ваш контент, и представляет объект, с которым взаимодействуют пользователи, когда они изменяют размер и перемещают ваше приложение на экране. Разработчики, знакомые с Win32, могут рассматривать AppWindow как высокоуровневую абстракцию HWND.
• Область отображения представляет собой высокоуровневую абстракцию HMONITOR, следует тем же принципам, что и AppWindow.
• DisplayAreaWatcher позволяет разработчику наблюдать за изменениями в топологии отображения и перечислять области отображения, определенные в настоящее время в системе.

вход

Это API-интерфейсы ввода, которые поддерживают WinUI и предоставляют разработчикам поверхность API более низкого уровня для достижения более сложных взаимодействий ввода.

Новые функции

• API-интерфейсы указателей: УказательТочка, Свойства указателяPointи PointEventArgs для поддержки получения информации о событии указателя с помощью входных API XAML.
• API InputPointerSource: представляет объект, зарегистрированный для отчета о вводе указателя, и предоставляет курсор указателя и обработку событий ввода для XAML SwapChainPanel API.
• Курсор API: позволяет разработчикам изменять растровое изображение курсора.
• API распознавания жестов: позволяет разработчикам распознавать определенные жесты, такие как перетаскивание, удерживание и щелчок, при наличии информации об указателе.

Важные ограничения

• Все УказательТочка статические фабричные функции были удалены: GetCurrentPoint, GetCurrentPointTransformed, Получить промежуточные очкии GetIntermediatePointsTransformed.
• Windows App SDK не поддерживает извлечение УказательТочка объекты с идентификаторами указателя. Вместо этого вы можете использовать УказательТочка функция-член GetTransformedPoint получить преобразованную версию существующего УказательТочка объект. Для промежуточных точек можно использовать PointEventArgs функции-члены Получить промежуточные очки и GetTransformedIntermediatePoints.
• Прямое использование SDK API платформы Windows.UI.Core.CoreDragOperation не будет работать с приложениями WinUI.
• УказательТочка свойства RawPosition и Контакты были удалены, потому что они ссылались на непрогнозируемые значения, которые были такими же, как нормальные значения в ОС. Использовать Позиция и КонтактыRect вместо. Предсказание указателя теперь обрабатывается с помощью Microsoft.UI.Input.PointerPredictor Объект API.

Жизненный цикл приложения

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

Приложения, отличные от UWP, также можно упаковывать в пакеты MSIX. Хотя эти приложения могут использовать некоторые функции жизненного цикла приложений Windows App SDK, они должны использовать подход манифеста, если он доступен. Например, они не могут использовать Windows App SDK. ЗарегистрироватьсяForXXXАктивация 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 получает Microsoft.UI.Xaml.LaunchActivatedEventArgs, тогда как платформа GetActivatedEventArgs возвращает Windows.ApplicationModel.IActivatedEventArgsи WindowsAppSDK GetActivatedEventArgs возвращает Microsoft.Windows.AppLifecycle.AppActivationArguments объект, который может представлять собой платформу LaunchActivatedEventArgs.
  • Для получения дополнительной информации см. Богатая активация.
• Зарегистрируйтесь/отмените регистрацию для расширенной активации
  • Неупакованные приложения: Полностью пригодный для использования.
  • Упакованные приложения: нельзя использовать вместо этого манифест приложения MSIX.
  • Для получения дополнительной информации см. Богатая активация.
• Одиночный/многоэкземплярный
  • Неупакованные приложения: Полностью пригодный для использования.
  • Упакованные приложения: Полностью пригодный для использования.
  • WinUI-приложения: если приложение хочет обнаружить другие экземпляры и перенаправить активацию, оно должно сделать это как можно раньше, до инициализации любых окон и т. д. WinMain (C++), где он может выполнять обнаружение и перенаправление.
  • Редиректактиватионтоасинк является асинхронным вызовом, и вам не следует ждать асинхронного вызова, если ваше приложение работает в STA. Для приложений Windows Forms и C# WinUI при необходимости можно объявить Main асинхронным. Для приложений C++ WinUI и C# WPF вы не можете объявить Main асинхронным, поэтому вместо этого вам нужно переместить вызов перенаправления в другой поток, чтобы убедиться, что вы не блокируете STA.
  • Для получения дополнительной информации см. Экземпляр приложения.
• Уведомления о питании/состоянии
  • Неупакованные приложения: Полностью пригодный для использования.
  • Упакованные приложения: Полностью пригодный для использования.
  • Для получения дополнительной информации см. Управление энергопотреблением.

Известная проблема:

• Сопоставления типов файлов неправильно кодируют %1 как %251 при настройке шаблона командной строки обработчика Verb, что приводит к сбою неупакованных приложений Win32. Вместо этого вы можете вручную изменить значение реестра на %1 в качестве частичного обходного пути. Если в пути к целевому файлу есть пробел, он все равно завершится ошибкой, и для этого сценария нет обходного пути.
• Эти ошибки с одним или несколькими экземплярами будут исправлены в следующем обновлении:
  • Перенаправление AppInstance не работает при компиляции для x86
  • Регистрация ключа, его отмена и повторная регистрация приводят к сбою приложения.

WriteCore

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

Особенности DWriteCore содержит все функции DirectWrite, за некоторыми исключениями.

Важные ограничения

• DWriteCore не содержит следующих функций DirectWrite:
  • Сессионные шрифты
  • Символьные шрифты, определяемые конечным пользователем (EUDC)
  • API потоковой передачи шрифтов
• Поддержка низкоуровневого API рендеринга является частичной.
• DWriteCore не взаимодействует с Direct2D, но вы можете использовать IDWriteGlyphRunAnaанализ и 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 или программу установки. Для получения дополнительной информации см. Руководство по развертыванию Windows App SDK для неупакованных приложений.
• Неупакованные приложения .NET также могут использовать оболочку .NET для API начальной загрузки для динамической зависимости от пакета платформы Windows App SDK во время выполнения. Дополнительные сведения об оболочке .NET см. Библиотека-оболочка .NET.
• Упакованные приложения могут использовать API развертывания для проверки и обеспечения того, чтобы на компьютере были установлены все необходимые пакеты. Дополнительные сведения о том, как работает API развертывания, см. руководство по развертыванию упакованных приложений.

Важные ограничения

• Оболочка .NET для API загрузчика предназначена только для использования неупакованными приложениями .NET для упрощения доступа к Windows App SDK.
• Только упакованные приложения MSIX, которые полностью доверяют или имеют Управление пакетами ограниченные возможности имеют разрешение на использование API развертывания для установки основных и одноэлементных зависимостей пакетов. Поддержка упакованных приложений с частичным доверием появится в более поздних выпусках.
• Когда F5 тестирует приложение x86, которое использует DeploymentManager.Инициализировать метод в системе x64, убедитесь, что платформа x64 сначала установлена, запустив WindowsAppRuntimeInstall.exe. В противном случае вы столкнетесь с НЕ НАЙДЕН ошибка из-за того, что Visual Studio не развертывает платформу x64, что обычно происходит при развертывании в магазине или загрузке неопубликованных приложений.

Другие ограничения и известные проблемы

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

  XMLКопировать

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

• Однопроектное приложение C# MSIX не компилируется, если не установлены инструменты C++ UWP. Если у вас есть однопроектный проект C# MSIX, вам потребуется установить C++ (v14x) Универсальные инструменты платформы Windows необязательный компонент.
• Последующий языковой VSIX не удается установить в Visual Studio 2019, если установлено несколько версий Visual Studio 2019. Если у вас установлено несколько версий Visual Studio 2019 (например, Release и Preview), а затем установите Windows App SDK VSIX для обоих C++ и C#, вторая установка завершится ошибкой. Чтобы решить эту проблему, удалите средства упаковки MSIX для одного проекта для 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 здесь.