はじめに
.NET Framework が2002年にリリースされてから20年という歳月が流れ、当初はWindows 専用でコンソールアプリやデスクトップアプリ、Webアプリのみの対応であったものが、.NET 6では、WindowsやLinuxやMac、iOSやAndroidなど様々なプラットフォーム上で動作するアプリやWebアプリ、IoT、ゲームなど様々なアプリ開発できるようになりました。さらに、たとえばWebアプリを開発する場合でも複数のテクノロジーが利用可能となっています。
その反面、あまりにできることが多すぎて、アプリを開発するときに自分のシナリオにあったテクノロジーを選択するための全貌を把握するのが困難になっています。
今回は新規アプリを開発するシナリオでも.NET Frameworkから.NET 6へ移行するシナリオでも、どのワークロードを利用するのがよいか迷わないように開発できるワークロードの種類と特長について概要を整理します。
逆にワークロードごとの詳細な情報は公式ドキュメントも充実しており検索で多数でヒットしますので、そちらを参照していただけますと幸いです。
ワークロードごとの主要なアプリテンプレート対応一覧
ほとんどの.NET Frameworkのワークロードには対応した.NET 6のワークロードが準備されていますが、一部対応する.NET 6のワークロードがないものがあります。また.NET5や.NET 6で新規に登場したワークロードもあります。
| 移行前（.NET Framework / mono） | 推奨移行先（.NET 6） | |||||
| アプリの種類 | ランタイム/SDK | プラットフォーム | アプリの種類 | ランタイム/SDK | プラットフォーム | |
| コンソール アプリ | コンソール | .NET Framework | Windows | コンソール | .NET 6 | Windows/Linux/macOS |
| Windows アプリ | Windows フォーム | .NET Framework | Windows | Windows フォーム | .NET 6 | Windows |
| WPF | .NET Framework | Windows | WPF | .NET 6 | Windows | |
| UWP | Universal Windows | Windows | WinUI | Windows App SDK | Windows | |
| Web アプリ | ASP.NET Web Forms | .NET Framework | Windows | 移行先なし | ||
| ASP.NET MVC | .NET Framework | Windows | ASP.NET Core MVC | .NET 6 | Windows/Linux/macOS | |
| Blazor Server | .NET 6 | Windows/Linux/macOS | ||||
| Blazor WebAssembly | .NET 6 | Windows/Linux/macOS | ||||
| モバイルアプリ | iOS | Xamarin.iOS | iOS | iOS | .NET 6 | iOS |
| Android | Xamarin.Mac | Android | Android | .NET 6 | Android | |
| Xamarin.Forms | Xamarin.Forms | Android/iOS/Windows(UWP) | .NET MAUI | .NET MAUI .NET 6 | Android/iOS/macOS/Mac Catalyst/Windows(WinUI) | |
| macOS アプリ | Mac | Xamarin.Mac | macOS | Mac Catalyst | .NET 6 | macOS/Mac Catalyst |
| Azure | Azure Functions | .NET Framework | Azure Functions (Runtime 1.x) | Azure Functions | .NET 6 | Azure Functions (Runtime 4.x) |
| Azure WebJobs | .NET Framework | Azure WebJobs | Azure WebJobs | .NET 6 | Azure WebJobs |
では、ワークロードごとの特長について、それぞれ解説していきます。
なお、以下で移行についても述べますが、ここでの「移行」とは、あくまでも.NET Frameworkアプリのソースコードを.NET 6でビルドし動作できるようにする最低限度の移行作業を意味しています。アプリケーションのモダナイゼーションを本格的に進めるような場合は、さらに追加の作業が必要となるのでご留意ください。
コンソールアプリ
・.NET Upgrade Assistant対応
コンソールアプリは.NET6でも引き続きサポートされています。「最上位レベルのステートメント」「暗黙的なusingディレクティブ」「グローバルusingディレクティブ」といった新機能によって.NET Framework時代より非常に簡潔にアプリケーションコードが記述できるようになっています。
もちろん、以前と同じスタイルでアプリケーションコードを記述することも可能です。.NET Upgrade Assistantに対応しており、.NET Frameworkアプリからの移行に関する手間も少なく、比較的容易に移行が可能です。
.NET Framework時代はWindows専用でしたが、.NET6ではWindows / Linux / macOSでの利用が可能になりました。
Windowsフォームアプリ
・.NET Upgrade Assistant対応
Windowsフォームアプリはすでに過去のものというイメージがあるかもしれませんが.NET6世代でも新規コントロールの追加や新機能の追加など手厚くサポートされておりまだまだ現役で利用可能です。
Windowsフォームの利点は何といっても初心者の開発者でも素早くアプリを開発できることなので、WPFやWinUI 3の難易度が高いと感じた場合や小規模のアプリであれば新規アプリに使用しても全く問題ありません。
MVVMのようなUIとロジックの分離についても公式のライブラリがないので多少手間がかかりますが、検索すれば多くの情報がヒットしますのでそれを参考にCommandやViewModelのベースを自前実装してしまえば分離可能です。
.NET FrameworkのWindowsフォームアプリからの移行先としても、.NET6のWindowsフォームアプリを第一の選択とすることをお勧めします。.NET Upgrade Assistantに対応しているため移行の一部も自動化できます。
.NET FrameworkのWindowsフォームアプリを.NET6のWPFに移行したいような場合は、結局大幅な改修となってしまうので移行ではなく新規開発としたほうがよいでしょう。
WPFアプリ
・.NET Upgrade Assistant対応
Windows デスクトップアプリを新規で開発するシナリオの場合、WPFかWinUI 3 にするかという選択になります。公式の推奨はWinUI 3なのですが、UWP系のGUIライブラリは短期間に方針が変わり迷走しているのでWinUI 3が今後も安定してサポートされ続け利用できるかということに少し疑問があります。（新たなライブラリが発表されWinUI 3が更新されなくなってしまう懸念）
逆にWPFは今後も長期間にわたってサポートされ続けると予想されますので、PC上でマウス操作するアプリを開発するならWPFが無難と言えます。（WPFはタッチ操作が一般的になる前にリリースされたライブラリのためタッチ操作にフレンドリーな設計になっていません。
タブレットでタッチ操作前提のアプリであればWinUI 3の方がお勧めとなります。
.NET FrameworkのWPFアプリの移行先としては.NET6のWPFアプリが推奨です。
UWPアプリ
これからUniversal Windows Platformアプリを新規で開発するならUWPアプリではなくWinUI 3アプリが推奨となります。
UWPはPC以外のWindowsデバイスでの動作も視野に入れていましたが、Windows Phoneが終了し、Surface Hubもあまり普及していませんのでUWPを新規で採用する理由はほぼありません。
マイクロソフトもUWPが実質的に互換性維持のために提供される状態へ入ったと意図する説明をしています。
既存アプリのアップグレードをする場合は、WinUI 3への移行となります。
WinUI 3アプリ
WinUI 3は2022年現在、開発に採用する場合においては少し慎重な判断が必要な立ち位置となっています。
WinUI 3はWindowsデスクトップアプリとUniversal Windows Platformアプリを開発可能です。
公式の推奨はWinUI 3なのですが、UWP系のGUIライブラリは短期間に方針が変わり迷走しているのでWinUI 3が今後も長期間安定して利用できるかということに疑問があります。ユーザーに受け入れられず、さらに新たなライブラリが発表され更新されなくなってしまう懸念があるので、ユーザーに受け入れられてしっかり普及するかどうか、もうしばらく様子見でもよいと考えられます。
また、WinUI 3はUWPをベースにしているため、使い勝手がWPFとは違う部分があるので、WPFに慣れておりWPFで事足りる場合はWPFを採用する方が無難です。
ASP.NET Web Forms アプリ
ASP.NET Web Formsは.NET Frameworkでのみ開発できます。.NET6に後継はありません。よって、現在、新規のWebアプリを開発するシナリオでASP.NET Web Formsを選択することはありません。
ASP.NET Web Formsアプリを.NET6に移行する場合、移行先としてはBlazor Server アプリが案内されていますが、実際には「移行」という範囲を超えたコードの書換えが必要になります。あくまでもBlazor Server アプリの設計思想がこれまでASP.NET Web Formsの開発者に理解しやすいという意味での案内となっています。
ASP.NET Web Forms は今後も.NET Framework 4.8のサポートが終了するまでサポートされますので、可能な限り現行のアプリを延命することが第一の選択になります。
どうしてもASP.NET Web Formsアプリを.NET6に移行したい場合、ASP.NET Core MVCアプリ、Blazor Serverアプリ、Blazor WebAssembly アプリのどれかに移行することになります。
ASP.NET MVC アプリ / ASP.NET Core MVC アプリ
・.NET Upgrade Assistant対応
ASP.NET Core MVC アプリを新規で開発するシナリオの場合、.NET６でもASP.NET Core MVCアプリとしてサポートされているので問題なく開発可能です。ただし、新規アプリを開発する場合には最初にサーバー上でロジックを実行しWebページのレンダリング結果をクライアントに送信する従来型のWebアプリかブラウザーでUIロジックの大部分を実行し、Web APIを介してサーバーと通信するシングルページアプリケーション (SPA) を選択する必要があります。
そのうえで、従来型のWebアプリであればASP.NET Core MVCをSPAであればBlazor ServerアプリまたはBlazor WebAssemblyを選択します。
Webアプリのテクノロジーの選択については以下の記事も参考になります。
参考情報：従来の Web アプリケーションかシングル ページ アプリケーション (SPA) を選択する
docs.microsoft.com
移行の場合であれば、.NET Upgrade Assistantに対応していますので、移行プロセスの一部は自動で実行可能です。なお、ASP.NET Core MVCでは起動プロセスの取り扱いとJavaScriptやCSSの配置方法が変更されているので書き換えが必要となります。
iOS アプリ
.NET でiOSアプリを開発するシナリオとして最も有効なのは、Windows アプリを iOS に移植したい場合でiOSらしいUXを実現したいというケースです。UIは再作成が必要ですが、ロジック部分はかなりの部分が流用可能です。
iOS アプリを新規で開発する場合、.NET６でもサポートされているので問題なく開発可能です。
2022年5月8日時点で.NET MAUIはRC2までリリースされていますので、近いうちにほとんど現状のままで正式版がリリースされると考えられます。
Visual Studio 上からはiOS アプリのテンプレートが選択できませんが、以下のようにコマンドでプロジェクトを新規作成できます。
dotnet new ios
移行の場合も、SDKの内容の変更はほとんどありませんので、.csprojファイルをSDKスタイルに書換えTFMを「net6.0-ios」に設定し、Visual Studio上のエラーや警告を修正すれば移行終了です。
今後正式版がリリースされた時点で何らかの自動アップグレードの手段が提供される可能性はあります。
Android アプリ
.NET でAndroidアプリを開発するシナリオとして最も有効なのは、Windows アプリを Androidに移植したい場合でAndroidらしいUXを実現したいというケースです。UIは再作成が必要ですが、ロジック部分はかなりの部分が流用可能です。
Androidアプリを新規で開発する場合、.NET６でもサポートされているので問題なく開発可能です。
2022年5月8日時点で.NET MAUIはRC2までリリースされていますので、近いうちにほとんど現状のままで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らしいUXにはそこまでこだわりがない場合があてはまります。UIは再作成が必要ですが、ロジック部分はかなりの部分が流用可能となります。
また、あまり複雑でないiOS/Androidのクロスプラットフォームアプリを開発したいが、開発者が.NETに慣れておりiOS/Androidには不慣れなケースもあてはまります。不慣れなことにチャレンジするよりはストレスなく始めることが可能となります。
なお、これからXamarin.Forms アプリを新規で開発する場合注意が必要です。
Xamarin.Formsは.NET MAUI の正式版がリリースされてから 1年後（2023年６月頃と予想されます）にサポートが終了するため、開発するアプリのリリース時期に応じて、一旦Xamarin.Forms で開発し.NET MAUIへ移行するか、今の時点で.NET MAUIのRC2を使って開発を進めてしまうか決めることになります。
.NET MAUI アプリ
.NET MAUIアプリを開発するシナリオとしては、（Xamarin.Formsと同じですが）Windows アプリを iOSとAndroidに移植したい場合でiOSやAndroidらしいUXにはそこまでこだわりがない場合があてはまります。UIは再作成が必要ですが、ロジック部分はかなりの部分が流用可能となります。
また、あまり複雑でないiOS/Androidのクロスプラットフォームアプリを開発したいが、開発者が.NETに慣れておりiOS/Androidには不慣れなケースもあてはまります。不慣れなことにチャレンジするよりはストレスなく始めることが可能となります。
.NET MAUIの正式版がリリースされた時点（2022年６月までにはリリースされる予定）からは.NET MAUI アプリを選択することが推奨になります。
Xamarin.Mac アプリ / Mac Catalyst アプリ
.NET でMacアプリを開発するシナリオとして最も有効なのは、Windows アプリを macOS に移植したいというケースです。UIやプラットフォームに依存のコードは再作成が必要ですが、プラットフォームに関係ないビジネスロジックのコードは流用可能です。
Macアプリを新規で開発する場合、.NET６でもサポートされているので問題なく開発可能です。
2022年5月8日時点で.NET MAUIはRC2までリリースされていますので、近いうちにほとんど現状のままで正式版がリリースされると考えられます。
Visual Studio 上からはMacアプリのテンプレートが選択できませんが、以下のようにコマンドでプロジェクトを新規作成できます。
dotnet new maccatalyst
移行の場合も、SDKの内容の変更はほとんどありませんので、.csprojファイルをSDKスタイルに書換えTFMを「net6.0-maccatalyst」に設定し、Visual Studio上のエラーや警告を修正すれば移行終了です。
今後正式版がリリースされた時点で何らかのXamarin.Macからの自動アップグレードの手段が提供される可能性はあります。
Blazor Serverアプリ/ Blazor WebAssembly アプリ
.NETでSPAを開発したいシナリオの場合Blazor Serverアプリを検討します。Blazorの場合Vueなどを利用する場合と比べて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#で記述することができます。コンセプトとしてはSilverlightに似ていますが、プラグインを使用ないことやオープンな Web 標準を使用している点がSilverlightより優れています。
Blazor ServerアプリとBlazor WebAssembly アプリのどちらを選択するかについては以下の記事も参考になります。
参考情報：どの Blazor ホスティング モデルを選択するか
docs.microsoft.com
Azure Functions
Azure Functionsの関数アプリを新規開発したい場合、.NET6での開発が推奨となります。
すでに稼働中の関数アプリを.NET6に移行したい場合は検証が必要ですが、関数アプリの性質上、互換性が問題となる影響があることはそれほど多くなく、発見された場合でも容易に修正が可能な場合が多いでしょう。
アプリケーションコードの移行については以下の記事も参考になります。
参考情報：既存のアプリのアップグレード
docs.microsoft.com
Azure WebJobs
・.NET Upgrade Assistant対応
WebJobsはApp Service上で定期的なプログラムを実行するシナリオやApp ServiceにデプロイされたWebアプリやAPIアプリ内からプログラムを実行させるシナリオで利用します。
WebJobsを新規開発したい場合、.NET6での開発が推奨となります。
.NET6の場合WebJobsのプロジェクトテンプレートが用意されていないので、コンソールアプリを作成し必要に応じてAzure WebJobs SDKインストールします。詳しい手順については以下の記事が参考になります。
参考情報：チュートリアル: イベント ドリブンのバックグラウンド処理に Azure WebJobs SDK の使用を開始する
docs.microsoft.com
.NET FrameworkのWebJobsからの移行先としては、要件によってはAzure Functionsに移行することも選択肢の一つとなります。
Functionsに移行すべきか、WebJobsのまま移行すべきかについては以下の記事も参考になります。
参考情報：Functions と WebJobs の比較
docs.microsoft.com
.NET6のWebJobsに移行する場合は.NET Upgrade Assistantに対応しているため移行の一部も自動化できます。
まとめ
.NET6はどんなプラットフォームで動くどんなアプリでも開発できるすばらしい開発環境になった反面、自分のシナリオに合ったワークロードの見極めが少々難しくなっています。
業務アプリケーションを開発する際に利用が想定されるワークロードについては一通り概要に触れることができました。
