Поделиться через

Заметки о выпуске стабильного канала для пакета SDK для приложений Windows 1.0

Стабильный канал предоставляет выпуски пакета SDK для приложений Windows, которые поддерживаются приложениями в рабочих средах. Приложения, использующие стабильный выпуск пакета SDK для приложений Windows, также можно опубликовать в Microsoft Store.

Важные ссылки:

Последняя версия стабильного канала:

Загрузки для Windows App SDK

Замечание

Расширения Visual Studio для пакета SDK для приложений Windows (VSIX) больше не распределяются в виде отдельной загрузки. Они доступны в Visual Studio Marketplace в Visual Studio.

Версия 1.0.4

Это сервисный выпуск пакета SDK для приложений Windows, содержащий критические исправления ошибок для версии 1.0.

Исправления ошибок (1.0.4)

  • Исправлена проблема, из-за которой AppBars при использовании в качестве Page.TopAppBar или Page.BottomAppBar не отображался на экране.
  • Исправлена проблема, из-за которой приложения с именем пакета 12 символов или меньше, которые используют элемент управления WinUI из MUXControls.dll немедленно завершатся сбоем. Дополнительные сведения см. в issue 6360 на сайте GitHub.
  • Исправлены проблемы с сенсорным вводом, вызывавшие проблемы с сочетаниями клавиш и другими сценариями. Дополнительные сведения см. в статье проблема 6291 на сайте GitHub.
  • Исправлена проблема, из-за которой не удается развернуть приложения, упакованные с помощью MSIX или развертываемые как автономные.
  • Исправлена проблема, из-за которой приложения иногда завершались сбоем во время операции перетаскивания. Дополнительные сведения см. в вопросе 7002 на GitHub.

Версия 1.0.3

Это сервисный выпуск пакета SDK для приложений Windows, содержащий критические исправления ошибок для версии 1.0.

Исправления ошибок (1.0.3)

  • Исправлена проблема, из-за которой приложения C# с WebView2 завершались сбоем при запуске, когда среда выполнения C/C++ (CRT) не установлена.
  • Исправлены проблемы с сенсорным вводом, вызывавшие проблемы с сочетаниями клавиш и другими сценариями. Дополнительные сведения см. в статье проблема 6291 на сайте GitHub.

Примечание. Обычно мы не добавляем функции в выпуск обслуживания, но исправление WebView2 в этой версии потребовало обновления до последней версии пакета SDK WebView2 (с 1020.46 до 1185.39). См. заметки о выпуске для пакета SDK WebView2 для получения дополнительной информации о версии WebView2 1.0.1185.39 и распространение приложения и среды выполнения WebView2 для дополнительной информации о среде выполнения WebView2.

Версия 1.0.2

Это сервисный выпуск пакета SDK для приложений Windows, содержащий критические исправления ошибок для версии 1.0.

Исправления ошибок (1.0.2)

  • Исправлена проблема с циклом обработки макета, приводившая к сбою приложения при прокрутке до конца ListView. Дополнительные сведения см. в задаче 6218 на GitHub.
  • Исправлена проблема, из-за которой приложения C# завершались сбоем при запуске, когда среда выполнения C/C++ (CRT) не установлена. Однако CRT по-прежнему требуется для приложений C# с помощью WebView2. Дополнительные сведения см. по вопросу №2117 в на GitHub.
  • Исправлена проблема, из-за которой приложения с одним проектом MSIX не создавали файл appinstaller. Дополнительные сведения см. в задаче 1821 на сайте GitHub.
  • Исправлена проблема, из-за которой приложения WinUI не поддерживали dotnet build.NET 6.

Версия 1.0.1

Это обслуживающий выпуск SDK для приложений Windows, включающий критические исправления ошибок и поддержку нескольких окон для версии 1.0.

Исправления ошибок (1.0.1)

  • Исправлена проблема, из-за которой mddBootstrapAutoinitializer не компилировался с включёнными implicitUsings. Дополнительные сведения см. в задаче 1686 на сайте GitHub.
  • Исправлена проблема, из-за которой фокус в WebView2 был неожиданно потерян, что приводило к проблемам ввода и выбора. Дополнительные сведения см. в задаче 5615 и задаче 5570 на GitHub.
  • Исправлена проблема, из-за которой панель инструментов в Visual Studio становилась некликабельной при использовании настраиваемой строки заголовка в приложении WinUI 3.
  • Исправлена проблема, из-за которой Snap Layout не отображался при использовании настраиваемой строки заголовка в приложении WinUI 3. Дополнительные сведения см. в вопросе 6333 и вопросе 6246 на GitHub.
  • Исправлена проблема, из-за которой возникало исключение при задании свойства Window.ExtendsContentIntoTitleBar при вызове метода Window.SetTitlebar, когда UIElement всё ещё загружается.
  • Исправлена проблема, по причине которой приложения MSIX с одним проектом не поддерживали dotnet build.
  • Исправлена проблема, из-за которой после установки упаковаемого приложения не устанавливались непакованные приложения. Для получения дополнительной информации см. вопрос 1871 на GitHub.
  • Исправлена проблема с снижением производительности во время операций перетаскивания мыши.
  • Исправлен сбой при вызове GetWindowIdFromWindow() в распакованных приложениях. Дополнительные сведения см. в обсуждении 1891 на сайте GitHub.

Ограничения и известные проблемы, для версии 1.0, также применяются к версии 1.0.1.

Кроме того, для приложений с настраиваемыми строками заголовков мы внесли изменения в этом выпуске (и исправили многочисленные проблемы), которые включают исправления в стеклянное окно, используемое для операций перетаскивания и сброса. Рекомендуется использовать значения и параметры по умолчанию (попробуйте их!). Если в строке заголовка использовались поля, чтобы кнопки заголовка по умолчанию были интерактивными, рекомендуется визуализировать область перетаскивания, установив фон строки заголовка красным и изменив поля, чтобы расширить область перетаскивания на элементы управления субтитрами.

Новые возможности

Мы стабилизировали и позволили создавать несколько окон в одном потоке в приложениях WinUI 3. Дополнительные сведения см. в выпуске 5918.

Версия 1.0

В следующих разделах описываются новые и обновленные функции, ограничения и известные проблемы для версии 1.0.

WinUI 3

WinUI 3 — это платформа пользовательского интерфейса (UX) для пакета SDK для приложений Windows. В этом выпуске мы добавили несколько новых функций из пакета SDK для приложений Windows 0.8 и стабилизировали проблемы из выпусков предварительной версии 1.0.

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

  • Мы добавили новые элементы управления (PipsPager, Expander, BreadcrumbBar) и обновили существующие элементы управления, чтобы отразить последние стили Windows из WinUI 2.6.
  • Упаковка MSIX для одного проекта поддерживается в WinUI путем создания нового приложения с помощью шаблона "Пустое приложение, упакованное…".
  • Теперь мы поддерживаем развертывание приложений WinUI 3, которые не упаковываются в Windows версии 1809 и выше. Дополнительную информацию см. в разделе Создание вашего первого проекта WinUI 3 (Windows App SDK).
  • Проекты WinUI 3 теперь могут задать целевую версию до Windows 10 версии 1809. Ранее они могут быть заданы только ниже версии 1903.
  • Встроенная панель инструментов, горячая перезагрузка и динамическое визуальное дерево для упакованных приложений WinUI поддерживаются в Visual Studio 2022 Предварительная версия 5 и Общедоступная версия.

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

  • Известные проблемы для как упакованных, так и распакованных приложений WinUI:

    • ошибка времени выполнения в приложениях C++ или C#, ссылающихся на компонент среды выполнения C++ Windows:

      • Чтобы устранить проблему, добавьте приведенный ниже целевой объект в конец .vcxproj компонента среды выполнения Windows:
      <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>
      • Ожидаемая ошибка будет похожа на ошибку WinRT — 0x80004005: "Не удается найти ресурс из ms-appx:///BlankPage.xaml".

  • Известные проблемы для приложений WinUI с одним проектом MSIX (пустой шаблон приложения, упакованный):

    • Отсутствует элемент меню "Пакет и публикация", пока не перезапустите Visual Studio: При создании нового приложения с использованием Single-project MSIX в Visual Studio 2019 и Visual Studio 2022 с помощью шаблона проекта "Пустое приложение, в пакете (WinUI 3 для настольных ПК)" команда публикации проекта не отображается в меню, пока не закройте и снова откройте Visual Studio.
    • Приложение C# с проектом MSIX для одного проекта не будет компилироваться без установки дополнительного компонента "C++ (v14x) Universal Windows Platform Tools". Дополнительную информацию см. в инструментах установки пакета SDK для приложений Windows.
    • Потенциальная ошибка во время выполнения в приложении с одним проектом MSIX, использующую типы, определенные в упоминаемом компоненте среды выполнения Windows: Чтобы устранить, вручную добавьте активируемые записи классов в appxmanifest.xml.
      • Ожидаемая ошибка в приложениях C# — COMException: класс не зарегистрирован (0x80040154 (REGDB_E_CLASSNOTREG)).
      • Ожидаемая ошибка в приложениях C++/WinRT — winrt::hresult_class_not_registered.

  • Известные проблемы для приложений WinUI 3 , которые не упакованы (неупакованные приложения):

  • Известные проблемы, связанные с упаковкой и развертыванием приложений WinUI:

    • Команда Package не поддерживается в приложениях WinUI с одним проектом MSIX (пустое приложение, упакованный шаблон). Вместо этого используйте команду Package & Publish для создания пакета MSIX.
    • Чтобы создать пакет NuGet из библиотеки классов C# с помощью команды Pack, убедитесь, что Configuration активен и соответствует Release.
    • Команда Pack не поддерживается в компонентах среды выполнения Windows C++ для создания пакета NuGet.

Дополнительные сведения о начале разработки с помощью WinUI см. в следующем разделе:

Окно

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

Новые возможности:

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

Дополнительные сведения см. в разделе "Управление окнами приложений" (пакет SDK для приложений Для Windows).

Ввод

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

Новые возможности:

  • API указателя: PointerPoint, PointerPointPropertiesи PointerEventArgs для поддержки получения сведений о событиях указателя с помощью интерфейсов API ввода XAML.
  • API InputPointerSource: представляет объект, зарегистрированный для отчета о вводе указателя, и предоставляет обработку указателя, включая курсор и события ввода, для API SwapChainPanel XAML.
  • API курсора: позволяет разработчикам изменять растровое изображение курсора.
  • API GestureRecognizer: позволяет разработчикам распознавать определенные жесты, такие как перетаскивание, удержание и клик при указании сведений указателя.

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

  • Все статические фабричные функции PointerPoint удалены: GetCurrentPoint, GetCurrentPointTransformed, GetIntermediatePointsи GetIntermediatePointsTransformed.
  • Пакет SDK для приложений Windows не поддерживает получение объектов PointerPoint с идентификаторами указателей. Вместо этого можно пользоваться функцией-членом PointerPointGetTransformedPoint, чтобы получить преобразованную версию существующего объекта PointerPoint. Для промежуточных точек можно использовать функции-члены PointerEventArgsGetIntermediatePoints и GetTransformedIntermediatePoints.
  • Прямое использование API пакета SDK платформы Windows.UI.Core.CoreDragOperation не будет работать с приложениями WinUI.
  • свойства PointerPointRawPosition и ContactRectRaw были удалены, так как они ссылались на непрогнозируемые значения, которые совпадали с обычными значениями в ОС. Вместо этого используйте Position и ContactRect. Прогнозирование указателя теперь обрабатывается с помощью объекта API Microsoft.UI.Input.PointerPredictor API.

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

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

Это важно

Если вы работаете с приложением UWP, перейдите к разделу "Миграция из UWP" в пакет SDK для приложений Windows.

Приложения, отличные от UWP, также могут быть упакованы в пакеты MSIX. Хотя эти приложения могут использовать некоторые функции жизненного цикла приложений пакета SDK для Windows, они должны использовать подход манифеста, где это доступно. Например, они не могут использовать Windows App SDK RegisterForXXXActivation API и вместо этого должны зарегистрироваться для расширенной активации с помощью манифеста.

Все ограничения для упакованных приложений также применяются к приложениям WinUI, которые упаковываются, и существуют дополнительные рекомендации, как описано ниже.

Важные вопросы:

  • Расширенная активация: GetActivatedEventArgs

  • Регистрация и отмена регистрации для расширенной активации

  • Однократное или многоуровневое развертывание

    • нераспакованные приложения: полностью пригодны для использования.
    • упакованные приложения: полностью пригодные к использованию.
    • приложения WinUI: если приложение хочет обнаружить другие экземпляры и перенаправить активацию, оно должно сделать это как можно раньше и перед инициализацией любых окон и т. д. Чтобы включить это, приложение должно задать DISABLE_XAML_GENERATED_MAIN и написать настраиваемый main (C#) или WinMain (C++), где оно может выполнять обнаружение и перенаправление.
    • RedirectActivationToAsync является асинхронным вызовом, и не следует ожидать асинхронного вызова, если приложение работает в STA. Для приложений Windows Forms и WinUI на C# при необходимости можно объявить Main асинхронным. Для приложений C++ WinUI и C# WPF невозможно объявить Main асинхронным, поэтому вместо этого необходимо переместить операцию перенаправления в другой поток, чтобы не блокировать STA.
    • Дополнительные сведения см. в разделе инстанцирование приложений с помощью API жизненного цикла приложений.

  • Уведомления о питании/состоянии системы

известные проблемы:

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

DWriteCore

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

Возможности:

DWriteCore содержит все функции DirectWrite с несколькими исключениями.

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

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

Дополнительные сведения см. в обзоре DWriteCore.

Ядро MRT

MRT Core — это упрощенная версия современной системы управления ресурсами Windows , которая распространяется в составе пакета SDK для приложений Windows.

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

  • В проектах .NET файлы ресурсов, скопированные в папку проекта, не индексируются на F5, если приложение уже создано. В качестве обходного решения перестройте приложение. Дополнительные сведения см. в выпуске 1503.

  • В проектах .NET, когда файл ресурсов добавляется в проект с помощью пользовательского интерфейса Visual Studio, файлы могут не индексироваться по умолчанию. Дополнительные сведения см. в выпуске 1786. Чтобы обойти эту проблему, удалите записи, приведенные ниже в ФАЙЛЕ CSPROJ:

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

  • Для непакетированных приложений C++ WinUI URI ресурсов создается неправильно. Чтобы обойти эту проблему, добавьте следующее в vcxproj:

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

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

Дополнительные сведения см. в разделе Управление ресурсами с помощьюMRT Core.

Развертывание

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

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

  • Оболочка .NET для API загрузчика предназначена только для использования распакованными приложениями .NET для упрощения доступа к пакету SDK для приложений Windows.
  • Только приложения MSIX, упакованные с полным уровнем доверия или имеющие ограниченную функциональность packageManagement, обладают разрешением использовать API развертывания для установки основных зависимостей и зависимостей одиночных пакетов. Поддержка упакованных приложений с частичным доверием появится в будущих версиях.
  • При проведении тестирования F5 приложения x86, использующего метод DeploymentManager.Initialize на системе x64, убедитесь, что сначала установлена платформа x64, выполнив WindowsAppRuntimeInstall.exe. В противном случае возникнет ошибка NOT_FOUND из-за того, что Visual Studio не развертывает платформу x64, что обычно происходит через развертывание в магазине или путем загрузки вручную.

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

  • Нет поддержки конфигурации сборки Any CPU. При добавлении Windows App SDK в существующее приложение или компонент .NET, поддерживающее Any CPU, необходимо указать нужную архитектуру: x86, x64 или arm64.

  • Переход с .NET 5 на .NET 6. При обновлении в интерфейсе Visual Studio могут возникнуть ошибки сборки. В качестве обходного решения вручную обновите TargetFrameworkPackage файла проекта следующим образом:

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

  • Приложение MSIX C# единого проекта не компилируется, если не установлены средства UWP для C++. Если у вас есть однопроектный проект MSIX для C#, необходимо установить необязательный компонент C++ (v14x) Средства универсальной платформы Windows.

  • При установке нескольких версий Visual Studio 2019 в Visual Studio 2019 не удается установить последующий язык VSIX. Если установлены несколько версий Visual Studio 2019 (например, Release и Preview) и затем установить Windows App SDK VSIX для C++ и C#, то вторая установка не удастся. Чтобы устранить эту проблему, удалите пакет инструментов Single-project MSIX для Visual Studio 2019 после установки первого языкового пакета VSIX. Просмотрите это замечание для получения дополнительных сведений об этой проблеме.

  • Альтернативой DispatcherQueue.TryEnqueue (для возобновления выполнения в потоке очереди диспетчера) является использование вспомогательной функции resume_foreground в библиотеке реализации Windows (WIL):

    1. Добавьте ссылку на пакет Microsoft.Windows.ImplementationLibrary NuGet в ваш проект.
    2. Добавьте #include <wil/cppwinrt_helpers.h> в pch.h.
    3. Добавьте #include <winrt/Microsoft.UI.Dispatching.h> в pch.h.
    4. Теперь co_await wil::resume_foreground(your_dispatcherqueue);.