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

Общая стратегия миграции

Введение

Windows App SDK предоставляет широкий набор API Windows с реализацией, которые отделены от ОС и выпускаются разработчикам через пакеты NuGet. В качестве разработчика с приложением Universal Windows Platform (UWP) вы можете использовать существующий набор навыков и исходный код, переместив приложение в Windows App SDK.

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

Большинство API Windows Runtime (WinRT) можно использовать Windows App SDK приложениями. Но есть некоторые из них, которые не поддерживаются в классических приложениях или имеют ограничения.

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

Для этих API мы покажем, какие альтернативные варианты следует использовать. Большинство этих альтернатив доступны в WinUI или через интерфейсы COM WinRT, доступные в Windows App SDK.

Например, мы увидим определенные сценарии пользовательского интерфейса, в которых необходимо отслеживать объект главного окна, а также использовать различные API на основе HWND и шаблоны взаимодействия, такие как IInitializeWithWindow::Initialize.

Примечание.

См. также Windows Runtime API, которые не поддерживаются в настольных приложениях. Windows App SDK приложения — это один из типов настольного приложения. Другие виды настольных приложений включают .NET настольные приложения и настольные приложения C/C++ Win32. Аудитория этого раздела — разработчики, желающие перенести свои проекты на любую из платформ, охватывающих различные типы настольных приложений, включая (но не ограничиваясь такими как) Windows App SDK приложения.

Мы хотели бы услышать отзывы об этом руководстве по миграции и о вашем собственном опыте миграции. Используйте раздел отзывов прямо в нижней части этой страницы, как показано ниже.

  • Для вопросов и отзывов о Windows App SDK или чтобы просто начать обсуждение, нажмите кнопку Этот продукт. Вы также можете начать обсуждение на вкладке Discussions репозитория WindowsAppSDK GitHub. Используя эти каналы, вы также можете рассказать нам, какую проблему вы пытаетесь решить, как вы пытались решить ее до сих пор, и что будет идеальным решением для вашего приложения.
  • Для получения отзывов о отсутствующих или неверных сведениях в этом руководстве по миграции используйте кнопку "Эта страница ".

Почему переход на Windows App SDK?

В Windows App SDK вы можете улучшить своё приложение, добавив новые функции платформы и современную библиотеку Windows UI 3 (WinUI), которая разрабатывается и предназначена для того, чтобы удовлетворить ожидания ваших пользователей.

Кроме того, Windows App SDK является обратно совместимым; он поддерживает приложения до Windows 10 версии 1809 (10.0; Сборка 17763)— также известная как обновление Windows 10 октября 2018 г.

Преимущества перехода на Windows App SDK многообразны. Ниже приведены некоторые рекомендации.

  • Последняя платформа пользовательского интерфейса и элементы управления, такие как WinUI 3 и WebView2.
  • Единая поверхность API на платформах настольных приложений.
  • Более частая частота выпусков, которая выпускается отдельно от Windows.
  • Согласованный интерфейс в версиях Windows.
  • совместимость .NET.
  • Обратная совместимость до Windows 10 версии 1809.
  • Улучшенная среда выполнения. См контейнер MSIX.

Дополнительные сведения см. в разделе Windows App SDK.

Обзор процесса миграции

Примечание.

Вы можете представить версию приложения UWP, которую вы хотите перенести, как исходное решение/проект (это исходный процесс миграции). Версия Windows App SDK — это целевое решение (это цель процесса миграции).

Установка Windows App SDK VSIX

Скачайте последнюю версию Windows App SDK из Windows App SDK загрузок и запустите установку.

Создание проекта

В Visual Studio Создайте свой первый проект. Например, используйте шаблон проекта WinUI Blank App (Packaged). Этот шаблон project можно найти в диалоговом окне Create новое диалоговое окно project, выбрав язык: C# или C++; платформа: Windows App SDK; тип project: WinUI или Desktop.

Вы увидите два проекта в Solution Explorer— один имеет значение (Desktop), а другой — как (пакет).

Сначала перенос кода с наименьшими зависимостями

Чтобы проиллюстрировать эту рекомендацию, рассмотрим пример использования PhotoLab. Для примера приложения PhotoLab один из очевидных подходов может начаться с миграции MainPage, так как это такой важный и заметный элемент приложения. Но если бы мы сделали это, то мы вскоре обнаружим, что MainPage имеет зависимость от представления DetailPage; и затем DetailPage имеет зависимость от модели Photo. Если бы мы следовали этому пути, то мы можем постоянно прерывать себя (переключение на работу над каждой вновь обнаруженной зависимостью). Конечно, мы не ожидали бы получить чистую сборку, пока не отследили все зависимости и, по сути, не перенесли весь проект за один раз.

Если же наоборот мы начнем с части проекта, которая не зависит ни от чего, и будем работать от нее (от наименее зависимой части к наиболее зависимой), то мы сможем сосредотачиваться на каждой части по очереди. И мы также бы смогли добиться чистой сборки после миграции каждого элемента и таким образом убедиться, что процесс миграции остаётся на правильном пути.

Поэтому при миграции собственных приложений рекомендуется сначала перенести код с наименьшими зависимостями.

Копирование файлов или копирование содержимого файла?

При миграции вы, конечно, будете копировать файлы ресурсов (а не содержимое файлов ресурсов). Но как насчет файлов исходного кода? В качестве примера давайте снова рассмотрим класс MainPage из примера PhotoLab и примера редактора фотографий.

C#. В версии C# (PhotoLab) MainPage состоит из файлов MainPage.xaml исходного кода и MainPage.xaml.cs.

C++/WinRT. В версии C++/WinRT (редактор фотографий) MainPage состоит из файлов исходного кода MainPage.xaml, MainPage.idlMainPage.hи MainPage.cpp.

Таким образом, у вас есть выбор между этими двумя вариантами:

  • (Рекомендуется) можно скопировать сами файлы (с помощью Проводника файлов), а затем добавить копии в целевой проект. Исключениями из этой рекомендации являются такие файлы, как App.xaml и App.xaml.cs, так как эти файлы уже существуют в целевом project, и содержат исходный код, характерный для Windows App SDK. Для этого вам нужно объединить имеющийся исходный код с исходным кодом из исходного проекта.
  • Или можно использовать Visual Studio для создания новых файлов Page (например, MainPage.xaml и MainPage.xaml.cs) в целевом проекте, а затем скопировать содержимое этих файлов исходного кода из исходного проекта в целевой проект. Для project C++/WinRT этот параметр включает гораздо больше шагов.

См. также раздел MainPage и MainWindow.

Различия имен папок и файлов (C++/WinRT)

В проекте C++/WinRT UWP файлы code-behind для представлений XAML имеют вид MainPage.h и MainPage.cpp. Но в Windows App SDK C++/WinRT необходимо переименовать их в MainPage.xaml.h и MainPage.xaml.cpp.

В проекте UWP C++/WinRT при переносе гипотетического представления XAML (в смысле моделей, представлений и моделей представлений) с именем MyPage в MyPage.xaml.cpp необходимо добавить #include "MyPage.g.cpp" сразу после #include "DetailPage.xaml.h". А для гипотетической модели с именем MyModelMyModel.cpp добавьте #include "MyModel.g.cpp" сразу после #include MyModel.h. Пример см. в исходном коде Migrate DetailPage.

Если вы измените имя перенесенного проекта

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

Изменение имени проекта (и, следовательно, имени пространства имен по умолчанию) — это то, что мы делаем, например, в случае миграции примера приложения UWP PhotoLab на SDK Windows App (C#). В этом примере вместо того, чтобы копировать содержимое из исходного проекта в целевой проект, мы копируем все файлы с помощью Проводника. Имя исходного project/пространства имен — PhotoLab, а целевое имя project или пространства имен — PhotoLabWinUI3. Поэтому нам нужно искать PhotoLab в содержимом всех файлов исходного кода, которые мы скопировали, и изменить его на PhotoLabWinUI3

В этом конкретном примере мы внесли эти изменения в App.xaml, App.xaml.cs, MainPage.xaml, , MainPage.xaml.cs, DetailPage.xamlDetailPage.xaml.csImageFileInfo.csи LoadedImageBrush.cs.

Установите те же пакеты NuGet, которые были установлены в исходном проекте.

Одна из задач во время процесса миграции заключается в определении каких-либо пакетов NuGet, от которых зависит исходный проект. Затем установите те же самые пакеты NuGet в целевой проект.

Например, в кейс-стади миграция примера приложения UWP PhotoLab на Windows App SDK (C#), исходный проект содержит ссылки на пакет NuGet Microsoft.Graphics.Win2D. В этом исследовании мы добавляем ссылки на тот же пакет NuGet в целевой проект.

  • Last updated on