全体的な移行戦略

[アーティクル]
03/28/2023

はじめに

Windows App SDK では、OS から切り離され、NuGet パッケージを介して開発者にリリースされた実装による、さまざまな Windows API のセットが提供されています。開発者はユニバーサル Windows プラットフォーム (UWP) アプリケーションを使用して、アプリを Windows App SDK に移動することで、既存のスキルセットとソースコードを有効に利用できます。

Windows App SDK を使用すると、最新のランタイム、言語、プラットフォームの機能をアプリに組み込むことができます。アプリケーションはそれぞれ異なっており、要件や設定もまた異なっているため、アプリのソースコードを移行するプロセスにアプローチするには多くのさまざまな方法があります。しかし、概要レベルのアプローチと、さまざまな機能領域に必要なコード変更は、どれも似ています。そのため、このトピックでは、アプリの移行に取り組む方法に関する戦略と、特定の機能領域に関する詳細情報 (および制限事項) を確認します。そのため、「UWP から WinUI 3 への移植時にサポートされる内容」も参照してください。

ほとんどの Windows ランタイム (WinRT) API は、Windows App SDK アプリで使用できます。ただし、デスクトップアプリでサポートされていないものや、制限があるものがあります。

UWP アプリでのみ使用するように設計された UI 機能に依存する API。
パッケージ ID が必要な API。これらの API は、MSIX を使用してパッケージ化されたデスクトップアプリでのみサポートされています。

これらの API については、使用する代替手段について説明します。これらの代替手段のほとんどは、Windows UI ライブラリ (WinUI) で、または Windows App SDK で使用できる WinRT COM インターフェイスを介して利用できます。

たとえば、メインウィンドウオブジェクトを追跡し、さまざまな HWND ベースの API と相互運用パターン (IInitializeWithWindow::Initialize など) を使用する必要がある特定の UI シナリオについて確認します。

Note

「デスクトップアプリでサポートされていない Windows ランタイム API」も参照してください。 Windows App SDK アプリは、デスクトップアプリの "1 つ" の種類です。その他の種類のデスクトップアプリには、.NET デスクトップアプリや C/C++ Win32 デスクトップアプリがあります。このトピックの対象読者は、Windows App SDK を含むがそれに限定されない、これらのさまざまな種類のデスクトップアプリを組み合わせたあらゆる移行先への移行を希望する開発者です。

この移行ガイドに関するフィードバックと、ご自身の移行経験に関するフィードバックをぜひお寄せください。このページの下にある「フィードバック」セクションを、次のようにご利用ください。

Windows App SDK に関する質問とフィードバックがある場合やディスカッションを開始する場合は、[This product](この製品) ボタンを使用してください。 WindowsAppSDK GitHub リポジトリの [ディスカッション] タブでディスカッションを開始することもできます。これらのチャネルを使用して、解決しようとしている問題、これまでに解決しようとした方法、アプリに最適なソリューションを連絡することもできます。
この移行ガイドの不足する情報や正しくない情報に関するフィードバックについては、[This page](このページ) ボタンを使用してください。

Windows App SDK に移行する理由

Windows App SDK を使用すると、新しいプラットフォーム機能だけでなく、ユーザーを満足させる目的で開発および設計された最新の Windows UI 3 ライブラリ (WinUI 3) を使用してアプリを強化することができます。

さらに、Windows App SDK には下位互換性があり、Windows 10 Version 1809 (10.0 ビルド 17763、Windows 10 October 2018 Update とも呼ばれています) までのアプリがサポートされています。

Windows アプリ SDKを移行する価値提案は多岐にわたります。次にいくつかの考慮事項を示します。

最新のユーザーインターフェイス (UI) プラットフォームとコントロール (Windows UI ライブラリ (WinUI) 3 やWebView2 など)。
デスクトップアプリプラットフォーム全体にわたる単一の API サーフェス。
Windows とは別途リリースされる、頻度の高いリリースサイクル。
Windows のバージョン間で一貫したエクスペリエンス。
.NET 互換性。
Windows 10 Version 1809 までの下位互換性。
ランタイム環境の改善。「MSIX コンテナー」を参照してください。

詳しくは、「Windows App SDK」を参照してください。

移行プロセスの概要

Note

移行するアプリの UWP バージョンは、"ソース" ソリューションまたはプロジェクト (移行プロセスの "ソース") とみなすことができます。 Windows App SDK バージョンが "ターゲット" ソリューションです (これが移行プロセスの "ターゲット" です)。

Windows App SDK VSIX をインストールする

Windows App SDK 用の安定したリリースチャネルから Windows App SDK Visual Studio 拡張機能 (VSIX) インストーラーをダウンロードし、実行してインストールします。

新しいプロジェクトの作成

Visual Studio で、最初の WinUI 3 プロジェクトを作成します。たとえば、[空のアプリ、パッケージ (デスクトップの WinUI 3)] プロジェクトテンプレートを使用します。そのプロジェクトテンプレートは、[新しいプロジェクトの作成] ダイアログで、言語は [C#] または [C++]、プラットフォームは [Windows App SDK]、プロジェクトの種類は [WinUI] または [デスクトップ] を選択して見つけることができます。

ソリューションエクスプローラーには 2 つのプロジェクトがあり、1 つは [(デスクトップ)] として、もう 1 つは [(パッケージ)] として修飾されています。

依存関係が最も少ないコードを最初に移行する

この推奨事項を説明するために、PhotoLab のケーススタディを例として見てみましょう。 PhotoLab サンプルアプリの場合、おそらく明白な 1 つのアプローチは、MainPage の移行から始めることです。なぜなら、これはアプリの重要で目立つ部分だからです。ただし、それをしようとすると、MainPage が DetailPage ビューに依存しており、その DetailPage は Photo モデルへの依存関係があることがすぐにわかります。その経路をたどった場合、絶えず自分の作業を中断する (依存関係が新しく見つかるごとに作業を切り替える) 可能性があります。すべての依存関係を追跡し、本質的に巨大なプロジェクトを 1 回で移植するまで、クリーンな "ビルド" を取得することは確かに期待できないでしょう。

一方、他の何にも依存しないプロジェクトの部分から始め、そこから外に向かって (依存が最も少ない部分から依存が最も多い部分に向かって) 作業する場合は、一度に 1 つずつ各部分に集中できます。そして、各部分を移行した後にクリーンなビルドが得られ、その方法で移行プロセスが順調に進んでいることを確認できます。

そのため、独自のアプリを移行する場合は、依存関係が最も少ないコードを最初に移行することをお勧めします。

ファイルをコピーするか、ファイルの内容をコピーするか?

移行する場合は、当然ですが、資産 "ファイル" をコピーします (資産ファイルの "内容" ではありません)。しかし、ソースコードファイルについてはどうでしょうか。例として、PhotoLab のケーススタディとフォトエディターのケーススタディから MainPage クラスを再び取り上げてみましょう。

C#。 C# バージョン (PhotoLab) では、MainPage は、ソースコードファイル MainPage.xaml と MainPage.xaml.cs で作成されています。

C++/WinRT。 C++/WinRT バージョン (フォトエディター) では、MainPage は、ソースコードファイル MainPage.xaml、MainPage.idl、MainPage.h、MainPage.cpp で作成されています。

そのため、次の 2 つのオプションから選択できます。

(推奨) (エクスプローラーを使用して) ファイル自体をコピーし、コピーをターゲットプロジェクトに追加できます。この推奨事項の例外は、App.xaml や App.xaml.cs などのファイルです。これらのファイルはターゲットプロジェクトに既に存在し、Windows App SDK に固有のソースコードが含まれています。これらの場合は、既に存在するソースコードをソースプロジェクトのソースコードと "マージする" 必要があります。
または、Visual Studio を使用して、ターゲットプロジェクトに新しいページ ファイル (MainPage.xaml やMainPage.xaml.cs など) を作成し、ソースプロジェクトからターゲットプロジェクトにそれらのソースコードファイルの "内容" をコピーすることができます。 C++/WinRT プロジェクトの場合、このオプションにはさらに多くの手順が必要になります。

「MainPage と MainWindow」のセクションも参照してください。

フォルダーとファイル名の違い (C++/WinRT)

C++/WinRT UWP プロジェクトでは、XAML ビューの分離コードファイルの名前は MainPage.h と MainPage.cpp の形式で指定されます。ただし、C++/WinRT Windows App SDK では、これらの名前を MainPage.xaml.h と MainPage.xaml.cpp に変更する必要があります。

C++/WinRT UWP プロジェクトで、MyPage.xaml.cpp の内部の MyPage という名前の仮定の XAML ビュー (モデル、ビュー、ビューモデルの意味) を移行する場合、#include "DetailPage.xaml.h" の直後に #include "MyPage.g.cpp" を追加する必要があります。また、MyModel.cpp の内部の MyModel という名前の仮定のモデルの場合、#include "MyModel.h" の直後に #include "MyModel.g.cpp" を追加します。例については、「DetailPage ソースコードを移行する」を参照してください。

移行したプロジェクトの名前を変更する場合

移行中に、ソースプロジェクトとは異なる名前をターゲットプロジェクトに付ける場合があります。そうすると、ソースプロジェクト内の既定の名前空間に影響します。ソースプロジェクトからターゲットプロジェクトにソースコードをコピーするとき、ソースコードに記載されている名前空間名を変更することが必要になる場合があります。

プロジェクト名 (および既定の名前空間名) の変更は、たとえばケーススタディ「UWP PhotoLab サンプルアプリの Windows App SDK の移行 (C#)」で行いました。このケーススタディでは、ソースからターゲットプロジェクトにファイルの "内容" をコピーする代わりに、エクスプローラーを使用してファイル全体をコピーします。ソースのプロジェクトまたは名前空間名は PhotoLab で、ターゲットのプロジェクトまたは名前空間名は PhotoLabWinUI3 です。そのため、コピーしたすべてのソースコードファイルの内容から PhotoLab を検索し、それを PhotoLabWinUI3 に変更する必要があります

特にこのケーススタディでは、App.xaml、App.xaml.cs、MainPage.xaml、MainPage.xaml.cs、DetailPage.xaml、DetailPage.xaml.cs、ImageFileInfo.cs、LoadedImageBrush.cs でこれらの変更を行いました。

ソースプロジェクトにインストールされたものと同じ NuGet パッケージをインストールする

移行プロセス中の 1 つのタスクは、ソースプロジェクトが依存しているすべての NuGet パッケージを特定することです。次に、それらの同じ NuGet パッケージをターゲットプロジェクトにインストールします。

たとえば、ケーススタディ「UWP PhotoLab サンプルアプリの Windows App SDK の移行 (C#)」では、ソースプロジェクトには Microsoft.Graphics.Win2D NuGet パッケージへの参照が含まれています。そのため、このケーススタディでは、同じ NuGet パッケージへの参照をターゲットプロジェクトに追加します。