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

Введение

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

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

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

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

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

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

Примечание.

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

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

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

Зачем переходить в пакет SDK для приложений Windows?

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

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

Ценность перемещения пакета SDK для приложений Windows — это многообразие. Ниже приведены некоторые рекомендации.

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

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

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

Примечание.

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

Установка пакета SDK для приложений Windows VSIX

Скачайте установщик пакета SDK для Приложений Windows Visual Studio (VSIX) из канала стабильных выпусков для пакета SDK для приложений Windows и запустите его, чтобы установить его.

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

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

В Обозреватель решений вы увидите два проекта: один из них имеет значение (Desktop), а другой — как (пакет).

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

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

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

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

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

При миграции вы, конечно, будете копировать файлы ресурсов (а не содержимое файлов ресурсов). Но как насчет файлов исходного кода? В качестве примера давайте снова рассмотрим класс 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, так как эти файлы уже существуют в целевом проекте, и они содержат исходный код, характерный для пакета SDK для приложений Windows. Для тех, кто вам потребуется объединить исходный код, который уже есть с исходным кодом из исходного проекта.
  • Или можно использовать Visual Studio для создания новых файлов страниц (например MainPage.xaml , и MainPage.xaml.cs) в целевом проекте, а затем скопировать содержимое этих файлов исходного кода из исходного проекта в целевой проект. Для проекта C++/WinRT этот параметр включает гораздо больше шагов.

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

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

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

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

При изменении имени перенесенного проекта

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

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

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

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

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

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