Windowsフォーム、ASP.NET、iOS、Android、Azure Functions――.NET 6で新規開発、移行できるアプリの技術まとめ：.NET 6移行入門（4）

.NET 6の現状を把握し、具体的な移行方法を学ぶ連載。今回は、.NET 6で新規開発、移行できるアプリの技術についてまとめる。

[鈴木友宏，NTTデータ先端技術株式会社]

　.NET Framework が2002年にリリースされてから20年という歳月が流れ、当初はWindows専用でコンソールアプリやデスクトップアプリ、Webアプリのみ開発可能だったものが、.NET 6では、WindowsやLinux、macOS、iOS、Androidなど多様なプラットフォーム上で、Webアプリ、IoT、ゲームといったアプリを開発できるようになりました。さらに、例えばWebアプリを開発する場合でも、複数の技術を利用できます。

　その半面、あまりにできることが多過ぎて、アプリを開発するときに自分のシナリオに合った技術を選択するために全貌を把握するのが困難になっています。

　.NET 6の現状を把握し、具体的な移行方法を学ぶ本連載「.NET 6移行入門」。今回は新規アプリを開発するシナリオでも.NET Frameworkから.NET 6に移行するシナリオでも、どのワークロードを利用すればよいか迷わないように、ワークロードの種類と特徴について概要を整理します。

　逆にワークロードごとの詳細な情報は公式ドキュメントも充実しており、検索できるので、そちらを参照していただければと思います。

ワークロードごとの主要なアプリテンプレート対応一覧

　下記の表の通り、.NET 6は、ほとんどの.NET Frameworkのワークロードに対応していますが、一部対応していないワークロードがあります。また.NET 5や.NET 6で新規に登場したワークロードもあります。

　以降、ワークロードごとの特徴を解説します。なお、移行についても述べますが、ここでの「移行」とは、あくまでも.NET Frameworkアプリのソースコードを.NET 6でビルドして動かせるようにする最低限度の移行作業を意味します。アプリのモダナイゼーションを本格的に進める場合、さらに追加の作業が必要となるのでご留意ください。

コンソールアプリ（.NET Upgrade Assistant対応）

　コンソールアプリは.NET 6でも引き続きサポートされます。「最上位レベルのステートメント」「暗黙的なusingディレクティブ」「グローバルusingディレクティブ」といった新機能によって、.NET Framework時代より簡潔にアプリのコードを記述できます。

　もちろん、以前と同じスタイルでもコードを記述できます。.NET Upgrade Assistantに対応しており、.NET Frameworkアプリから移行する手間が少なく、比較的容易な移行が可能です。

　.NET Framework時代はWindows専用でしたが、.NET 6ではWindows、Linux、macOSで利用できます。

Windowsフォームアプリ（.NET Upgrade Assistant対応）

　Windowsフォームアプリは既に過去のものというイメージがあるかもしれませんが、.NET 6世代でも新規コントロールの追加や新機能の追加など手厚くサポートされており、現役で利用可能です。

　Windowsフォームの利点は何といっても初心者でも素早くアプリを開発できることなので、「WPF（Windows Presentation Foundation）やWinUI 3の難易度が高い」と感じた場合や、小規模のアプリなら、Windowsフォームを新規アプリに使用しても全く問題ありません。

　MVVM（Model View ViewModel）のようなUIとロジックの分離についても公式のライブラリがないので多少手間がかかりますが、検索すれば多くの情報があるので、それを参考にCommandやViewModelのベースを自前実装してしまえば分離可能です。

　.NET FrameworkのWindowsフォームアプリからの移行先としても、.NET 6のWindowsフォームアプリを第一選択肢としてお薦めします。.NET Upgrade Assistantに対応しているので移行の一部を自動化できます。

　.NET FrameworkのWindowsフォームアプリを.NET 6のWPFに移行する場合、結局大幅な改修となるので、移行ではなく新規で開発した方がよいでしょう。

WPFアプリ（.NET Upgrade Assistant対応）

　Windowsデスクトップアプリを新規で開発する場合、WPFとWinUI 3のどちらを使うか選択することになります。公式の推奨はWinUI 3ですが、UWP（Universal Windows Platform）系のGUIライブラリの方針が短期間で変わっているといった理由から、WinUI 3が今後も安定してサポートが継続されるかどうかは少し疑問があります（新たなライブラリが発表され、WinUI 3が更新されなくなってしまう懸念）。

　逆にWPFは今後も長期間にわたってサポートされ続けることが予想されるので、PC上でマウス操作するアプリを開発するならWPFが無難といえます。なおWPFは、タッチ操作が一般的になる前にリリースされたライブラリなので、タッチ操作にフレンドリーな設計になっていません。タブレットでタッチ操作する前提のアプリを開発する場合、WinUI 3の方がお薦めです。

　.NET FrameworkのWPFアプリの移行先としては.NET 6のWPFアプリが推奨されます。

UWPアプリ

　これからUWPアプリを新規で開発するなら、UWPアプリではなくWinUI 3アプリが推奨となります。UWPはPC以外のWindowsデバイスでの動作も視野に入れていましたが、Windows Phoneが終了し、Surface Hubもあまり普及していないので、UWPを新規で採用する理由はほぼありません。

　MicrosoftもUWPが実質的に互換性維持のために提供される状態になったことを意図する説明をしています。既存アプリのアップグレードをする場合は、WinUI 3に移行します。

WinUI 3アプリ

　WinUI 3は2022年現在でアプリ開発に採用する場合、少し慎重な判断が必要です。

　WinUI 3はWindowsデスクトップアプリとUWPアプリを開発できます。公式の推奨はWinUI 3ですが、UWP系のGUIライブラリは短期間で繰り返し方針が見直されていることから、WinUI 3が今後も長期間安定して利用できるかどうか疑問です。ユーザーに受け入れられず、さらに新たなライブラリが発表されて更新されなくなる懸念があるので、ユーザーに受け入れられてしっかり普及するかどうか、もうしばらく様子見でもよいと考えます。

　WinUI 3はUWPをベースにしており、使い勝手がWPFとは違う部分があるので、WPFに慣れていてWPFで事足りる場合、WPFを採用する方が無難です。

ASP.NET Web Forms

　ASP.NET Web Formsは、.NET Frameworkでのみ開発できます。.NET 6に後継はありません。現在、新規のWebアプリを開発する場合、ASP.NET Web Formsを選択することはありません。

　ASP.NET Web Formsアプリを.NET 6に移行する場合、移行先としてはBlazor Serverアプリが案内されていますが、「移行」という範囲を超えたコードの書き換えが必要になります。あくまでも「これまでASP.NET Web Formsで開発してきた人にとって、Blazor Serverアプリの設計思想は理解しやすい」という意味での案内です。

　ASP.NET Web Formsは今後も.NET Framework 4.8のサポートが終了するまでサポートされるので、可能な限り現行のアプリを延命することが第一の選択肢です。

　どうしてもASP.NET Web Formsアプリを.NET 6に移行したい場合、ASP.NET Core MVCアプリ、Blazor Serverアプリ、Blazor WebAssemblyアプリのどれかに移行することになります。

ASP.NET MVCアプリ、ASP.NET Core MVCアプリ（.NET Upgrade Assistant対応）

　ASP.NET Core MVCアプリを新規で開発する場合、.NET 6でもASP.NET Core MVCアプリとしてサポートされているので問題なく開発できます。

　ただし、新規アプリを開発する場合、最初にサーバ上でロジックを実行し、Webページのレンダリング結果をクライアントに送信する従来型のWebアプリかブラウザでUIロジックの大部分を実行し、Web APIを介してサーバと通信するシングルページアプリ（SPA）を選ぶ必要があります。その上で、従来型のWebアプリならASP.NET Core MVCを、SPAならBlazor ServerアプリまたはBlazor WebAssemblyを選択します。

　Webアプリのテクノロジーの選択については下記も参考になります。

• 従来の Webアプリかシングル ページアプリ (SPA) を選択する

　移行の場合、.NET Upgrade Assistantに対応しているので、移行プロセスの一部は自動で実行できます。なおASP.NET Core MVCでは、起動プロセスの取り扱いとJavaScriptやCSSの配置方法が変更されているので、書き換えが必要です。

iOSアプリ

　.NETでiOSアプリを開発するシナリオとして最も有効なのは、WindowsアプリをiOSに移植したい場合でiOSらしいUIを実装したいケースです。UIは再作成が必要ですが、ロジック部分はかなりの部分が流用可能です。

　iOSアプリを新規で開発する場合、.NET 6でもサポートされているので問題なく開発可能です。

　2022年5月19日時点で.NET MAUIはRC（リリース候補版）3までリリースされているので、近いうちにほとんど現状のままで正式版がリリースされると考えられます。Visual StudioではiOSアプリのテンプレートを選択できませんが、次のようにコマンドでプロジェクトを新規作成できます。

dotnet new ios

　移行の場合も、SDKの内容の変更はほとんどないので、.csprojファイルをSDKスタイルに書き換えてTFM（Target Framework Monikers）を「net6.0-ios」に設定し、Visual Studio上のエラーや警告を修正すれば移行終了です。

　今後正式版がリリースされた時点で何らかの自動アップグレードの手段が提供される可能性があります。

Androidアプリ

　.NETでAndroidアプリを開発するシナリオとして最も有効なのは、WindowsアプリをAndroidに移植したい場合でAndroidらしいUIを実現したいケースです。UIは再作成が必要ですが、ロジック部分はかなりの部分が流用可能です。

　Androidアプリを新規で開発する場合、.NET 6でもサポートされているので問題なく開発可能です。

　2022年5月19日時点で.NET MAUIはRC3までリリースされているので、近いうちにほとんど現状のままでGA（一般提供）されると考えられます。Visual StudioではAndroidアプリのテンプレートを選択できませんが、次のようにコマンドでプロジェクトを新規作成できます。

dotnet new android

　移行の場合も、SDKの内容の変更はほとんどないので、.csprojファイルをSDKスタイルに書き換えてTFMを「net6.0-android」に設定し、Visual Studio上のエラーや警告を修正すれば移行終了です。

　今後正式版がリリースされた時点で何らかの自動アップグレードの手段が提供される可能性があります。

Xamarin.Formsアプリ

　Xamarin.Formsアプリを開発するシナリオとしては、WindowsアプリをiOSとAndroidに移植したい場合で、iOSやAndroidらしいUIにはそこまでこだわりがないケースが当てはまります。UIは再作成が必要ですが、ロジック部分はかなりの部分が流用可能となります。

　また、あまり複雑ではないiOS／Androidのクロスプラットフォームアプリを開発したいが、開発者が.NETに慣れており、iOS／Androidには不慣れなケースも当てはまります。不慣れなことにチャレンジするよりはストレスなく始めることが可能です。

　なお、これからXamarin.Formsアプリを新規で開発する場合注意が必要です。Xamarin.Formsは2023年11月にサポートが終了するので、開発するアプリのリリース時期に応じて、いったんXamarin.Formsで開発して.NET MAUIに移行するか、今の時点で.NET MAUIのRC版を使って開発を進めてしまうか決めることになります。

.NET MAUIアプリ

　.NET MAUIアプリを開発するシナリオとしては、（Xamarin.Formsと同じですが）WindowsアプリをiOSとAndroidに移植したい場合でiOSやAndroidらしいUXにはそこまでこだわりがないケースが当てはまります。UIは再作成が必要ですが、ロジック部分はかなりの部分が流用可能となります。

　また、あまり複雑ではないiOS／Androidのクロスプラットフォームアプリを開発したいが、開発者が.NETに慣れておりiOS／Androidには不慣れなケースも当てはまります。不慣れなことにチャレンジするよりはストレスなく始めることが可能です。

　.NET MAUIの正式版がリリースされた時点（2022年6月までにはリリースされる予定）からは.NET MAUIアプリを選択することが推奨されます。

Xamarin.Macアプリ、Mac Catalystアプリ

　.NETでmacOSアプリを開発するシナリオとして最も有効なのは、WindowsアプリをmacOSに移植したいケースです。UIやプラットフォームに依存するコードは再作成が必要ですが、プラットフォームに関係ないビジネスロジックのコードは流用可能です。

　macOSアプリを新規で開発する場合、.NET 6でもサポートされているので問題なく開発できます。

　2022年5月8日時点で.NET MAUIはRC2までリリースされているので、近いうちにほとんど現状のままで正式版がリリースされると考えられます。

　Visual StudioではmacOSアプリのテンプレートを選択できませんが、次のようにコマンドでプロジェクトを新規作成できます。

dotnet new maccatalyst

　移行の場合も、SDKの内容の変更はほとんどないので、.csprojファイルをSDKスタイルに書き換えTFMを「net6.0-maccatalyst」に設定し、Visual Studio上のエラーや警告を修正すれば移行終了です。

　今後正式版がリリースされた時点で何らかのXamarin.Macからの自動アップグレードの手段が提供される可能性があります。

Blazor Serverアプリ、Blazor WebAssemblyアプリ

　.NETでSPAを開発したい場合、Blazor Serverアプリを検討します。Blazorの場合Vue.jsなどを利用する場合と比べてJavaScriptへの深い理解が不要となるので、.NETに慣れておりJavaScriptの経験が浅い開発者がSPAを開発するシナリオでは有効な選択肢となります。

　Blazor Serverアプリでは、ロジックをC#で記述し、サーバ上で実行します。クライアントのブラウザ側はプレーンなHTMLとJavaScriptとなり、UIが操作されることでロジックの動作や画面の更新などが必要になった場合はサーバとSignalR通信が行われ、返ってきたレスポンスでブラウザのUIが更新されます。この動作モデルがASP.NET WebFormと似ているので、公式ではASP.NET WebFormの移行先としてBlazor Serverアプリを推奨しています。

　.NETでBlazor ServerアプリよりもさらにリッチなUIを提供したいシナリオや、サーバとの通信が不要なWebアプリを提供したいシナリオではBlazor WebAssemblyアプリを検討します（もちろん、Blazor WebAssemblyアプリでもサーバとの通信は利用できます）。

　Blazor WebAssemblyアプリはその名の通り、C#でWebAssemblyアプリを開発できます。WebAssemblyはブラウザ上で動作する高度なUIを、JavaScriptに不慣れな開発者でもC#で実装できます。コンセプトとしてはMicrosoft Silverlightに似ていますが、プラグインを使用しないことやオープンなWeb標準を使用している点がSilverlightより優れています。

　Blazor ServerアプリとBlazor WebAssemblyアプリのどちらを選択するかについては下記も参考になります。

• どの Blazor ホスティング モデルを選択するか

Azure Functions

　Azure Functionsの関数アプリを新規開発したい場合、.NET 6での開発が推奨となります。

　既に稼働中の関数アプリを.NET 6に移行したい場合は検証が必要ですが、関数アプリの性質上、互換性が問題となる影響はあまりなく、発見された場合でも容易に修正可能な場合が多いでしょう。

　アプリのコードの移行については下記も参考になります。

• 既存のアプリのアップグレード

Azure WebJobs（.NET Upgrade Assistant対応）

　Azure WebJobsはAzure App Service上で定期的なプログラムを実行するシナリオやAzure App ServiceにデプロイされたWebアプリ、またはAPIアプリ内からプログラムを実行させるシナリオで利用します。

　Azure WebJobsを新規開発したい場合、.NET 6での開発が推奨となります。.NET 6の場合はAzure WebJobsのプロジェクトテンプレートが用意されていないので、コンソールアプリを作成して必要に応じてAzure WebJobs SDKをインストールします。詳しい手順については下記が参考になります。

• チュートリアル: イベント ドリブンのバックグラウンド処理に Azure WebJobs SDK の使用を開始する

　Azure WebJobsからの.NET Frameworkの移行先としては、要件によってはAzure Functionsに移行することも選択肢の一つとなります。

　Azure Functionsに移行すべきか、Azure WebJobsのまま移行すべきかについては下記も参考になります。

• Functions と WebJobs の比較

　.NET 6のWebJobsに移行する場合、.NET Upgrade Assistantに対応しているので移行の一部も自動化できます。

まとめ

　.NET 6はどんなプラットフォームで動くアプリでも開発できるようになった半面、自分のシナリオに合ったワークロードの見極めが少々難しくなっています。

　本稿では、業務アプリを開発する際に利用が想定されるワークロードについては一通り概要を紹介しました。自身のシナリオに合ったアプリを開発する際の一助になれば幸いです。