次の方法で共有

全体的な移行戦略

  • [アーティクル]

はじめに

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 については、使用する代替手段について説明します。 これらの代替のほとんどは、WinUI 3 で、または Windows 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) プラットフォームと 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 パッケージへの参照をターゲット プロジェクトに追加します。