.NET 5世代のALMを意識した、.NET Frameworkアプリのワークロードごとの.NET 5移行戦略：.NET 5モダナイズ入門（2）

既存の.NET Frameworkアプリの.NET 5への移行に関する考慮事項やレガシーアプリのモダナイゼーションについて解説する連載。今回は、.NET Frameworkから.NET 5へのワークロードごとの移行方法の概要や参考情報などを紹介します。

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

　既存の.NET Frameworkアプリの.NET 5への移行に関する考慮事項やレガシーアプリのモダナイゼーションについて解説する本連載「.NET 5モダナイズ入門」。前回は.NET統合の現状や.NET 5のリリースにおけるキャッチアップすべきことなどについて解説しました。今回は、.NET 5世代のアプリケーションライフサイクルマネジメント（ALM）および、.NET Frameworkから.NET 5へのワークロードごとの移行方法の概要や参考情報などを紹介します。

.NET 5世代のアプリケーションライフサイクルマネジメント

　既存の.NET Frameworkアプリケーションを、できるだけ良い形で.NET 5または、それ以降のバージョンの.NETへ移行するためにはどうしたらよいのでしょうか。最も重要なのは、アプリケーションのライフサイクルに対する考え方の違いを理解することです。その上で、.NET Frameworkと.NET 5の技術上の違いを把握し、移行戦略を立てることです。

　.NET 5のアプリケーションのサポートポリシーについては下記の公開情報があります。

• .NET Coreおよび.NET 5のサポートポリシー

　上記の通り、.NET 5はLong Term Support（LTS）ではないため、.NET 6リリースの3カ月後（2022年2月ごろ）にサポート終了となります。LTSである.NET 6は、リリース後3年間、または次のLTSリリースの出荷後12カ月のメンテナンス期間のいずれか長い方でサポートされることになっています。従って、現時点から大規模なアプリケーションの移行を考える場合にはLTSである.NET 6をターゲットにするとスムーズに進められると考えられます。

　つまり、今後はLTSであっても3年程度しかサポート期間がない前提でアプリケーションの保守を考える必要があり、次のLTSバージョンがリリースされたら新しいLTSバージョンに移行し続ける必要があります。企業向けアプリケーションにとっては非常に厳しい要件となりますが、このようなライフサイクルになったのには理由があると考えられます。

　これは、完全に筆者の予想ですが、おそらく昨今の技術やセキュリティ要件の進化のスピードに対応し、競合企業との競争もある中で、アプリケーションのプラットフォームやクラウドのプラットフォームなどを現実的な価格で継続して提供し続けるには、LTSで3年のサポート期間が現実的な落としどころだったのではないでしょうか。

　この傾向は今後もしばらくは変わらない可能性が高いので、アプリケーションを運用する企業側が、新しいライフサイクルポリシーに対応できるように自社の体制を整えていく。そして、アプリケーション開発を請け負う企業側も、今後に即して提案したり、開発したりできるように変わっていく必要があります。

リリース後に塩漬けするのではなく、継続的な開発へ移行する

　今後の.NETライフサイクルの下では、長いサポート期間を前提に一気に大規模アプリケーションを開発し、その後は最低限度の対応だけで塩漬けにして運用することは難しくなります。継続的に技術力を保持しアプリケーションを改善していくためには、長期的にチームを維持し継続的にリリースしていく体制に変える必要があるでしょう。

　クラウドを利用する観点から考えても、例えばPaaSである「Azure App Service」の場合、当該バージョンの.NETのサポートが終了すれば、程なくしてAzure App Serviceでのサポートも終了します。また、アプリケーションのランタイムだけではなくTLSなどのサポートも、業界全体の流れに従い古いバージョンのサポートは終了していきます。つまり、クラウド上でアプリケーションを運用する場合、オンプレミスと違い、利用できるテクノロジーの主導権はプラットフォーマー側にあり、ユーザー側にはないのです。

　また、サポートが終了してしまえば、文字通り利用できなくなってしまうので（裏技的な利用方法が使える場合もありますが、更新プログラムが適用されないなど制限があるので、時間稼ぎにしかなりません）、短期間でアプリケーションをマイグレーションできるノウハウおよび体制が必要となります。

　なお.NET 6をターゲットにする場合、今まで.NET Frameworkでの開発しか経験がないと、いきなり大規模アプリケーションの移行に挑戦するのはリスクが大き過ぎます。.NET 6の正式リリースは2021年11月の予定なので、まずは、アプリケーションの一部や小規模なアプリケーションの.NET 5移行を検証したり、小規模な.NET 5のアプリケーションを一から開発したりして、一定の経験を積んだ上で大規模アプリケーションの移行について戦略を立てた方がよいでしょう。

　今は働き方を変えていく外圧が非常に高まっています。それは同時に、アプリケーションのライフサイクルに対する考え方を大きく変えるような提案の承認をもらう好機ともいえます。従って、移行戦略を立てる上では、これまでの自社の慣習や前例から選択肢を絞ることはせず、白紙の状態から選択肢を検討することをお勧めします。

ワークロード別.NET Frameworkから.NET 5への移行に関する情報まとめ

　次に.NET Frameworkの代表的なワークロードごとの移行に関する情報を紹介します。ここでの「移行」とは、あくまでもソースコードを.NET 5でビルドし動作できるようにする最低限度の移行作業を意味しています。アプリケーションのモダナイゼーションを本格的に進める場合は、さらに追加の作業が必要となるので、ご留意ください。

ASP.NET MVC（.NET Framework）からASP.NET Core MVC（.NET 5）

　ASP.NET MVCについては、.NET 5でも継続してサポートされているため、比較的移行が容易です。アプリケーションのスタートアップなどが異なっていますが、比較的移行の負担は小さくなっています。

　スタートアップは、ASP.NET MVC（.NET Framework）では、「Global.asax」が使用されていましたが、ASP.NET Coreアプリケーションでは「Startup.cs」が使用されています。

　移行の概要については、下記の公式情報を参照ください。

• 参考情報：ASP.NET MVCからASP.NET Core MVCへの移行

　なお、Startupクラス内での処理も変更されています。詳細は下記の公式情報を参照ください。

• 参考情報：ASP.NET Coreでのアプリケーションのスタートアップ

ASP.NET Web Forms（.NET Framework）からBlazor（.NET 5）への移行

　残念ながら、.NET 5において、ASP.NET Web Formsはサポートされません。ASP.NET Web Formsは社内システムなどで使われている方も多いと思いますが、下記の通り、Blazorが移行先として推奨されており、移行のためのドキュメントも提供されています。

• 参考情報：ASP.NET Web Forms開発者向けBlazorの紹介

　ですが、Blazorへの移行は、テクノロジーが異なるため、あくまでも、.NET 5で提供されているアプリケーションパターンの中では、一番移行に適しているだけであり、今までのソースコードをそのまま流用し調整するだけで移行できるわけではありません。UIに依存するコードは、ほぼ全てを捨てることになります。

　Blazorには、Web AssemblyとServerの2つのホスティングモデルがありますが、ASP.NET Web Forms開発者にとって違和感が少ないのはBlazor Serverホスティングモデルです。

• 参考情報：ASP.NET Core Blazorのホスティングモデル - Blazor Server

　なお、下記ブログにあるように、「どちらもサーバ上でコードをレンダリングし、両方ともコンポーネントベースのモデルを持っている」点で、BlazorとASP.NET Web Formsはコンセプトが似ています。

• 参考情報：What's Old is New Again - Web Forms meets Blazor

　さらに、UIのコードに、互換性がない問題をクリアするため、aspxのコードをごくわずかな書き換えでそのまま利用できるように、Blazorで ASP.NET Web Formsと同じ名前とマークアップおよび機能を持つコンポーネントを提供する下記ライブラリの開発も進められています。

• 参考情報：Blazor Web Forms Components

　本来、Blazorへの移行が検討されるようなASP.NET Web Formsアプリケーションは、完全な書き直しの方が適している可能性が高いですが、選択肢は多い方がよく、しっかり保守されており、UI層以下がモダンなアプリケーションであれば、書き直しをしない選択肢も検討の価値があります。また、このようなライブラリを検証することで移行を検討しているアプリケーションの移行戦略についての理解を深めることもできます。

WPF（.NET Framework）からWPF（.NET 5）

　現時点で、公式の情報が出そろっていませんが、WPF（Windows Presentation Foundation）の移行は比較的容易です。

• 参考情報：Differences in WPF（現時点では英語版のドキュメントのみ公開されております。また、.NET 5への移行は作成中で、.NET Core3.0への移行に関する内容になっています）
• 参考情報：Migrating WPF apps to.NET Core（現時点では英語版のみ公開されております。また、.NET 5への移行は作成中で、.NET Core3.0 への移行の内容になっています）

Windows Forms（.NET Framework）からWindows Forms（.NET 5）

　当初.NET CoreでサポートされていなかったWindows Formsも、.NET 5でも引き続きサポートされます。

• 参考情報：Windows Formsデスクトップアプリを.NET 5に移植する方法

　なお下記のように、.NET 5を含む.NET Coreで使用できない.NET Frameworkテクノロジーもあるのでご注意ください。

• 参考情報：.NET Coreと.NET 5以降で使用できない.NET Frameworkテクノロジー

　また、破壊的変更もあるので、併せてご注意ください。

• 参考情報：Windows Formsでの破壊的変更（.NET Core全体の情報）
• 参考情報：Windows Formsでの破壊的変更（.NET 5固有の情報）

　以上のように、主なワークロードにおいては、.NET 5リリースまでに手厚いサポートが行われており、ASP.NET Web Forms以外は、ソースコードの移行については比較的容易に実施できるようになっています。

　もちろん移行を進めていく段階では、さまざまな問題が出てくると思いますが、移行を進める環境としての前提条件は十分にそろっているといえます。

検証の重要性

　大きな変化を伴うアプリケーション移行を検討する場合は特に、ナレッジとして理解するだけではなく、ある程度の方向性を決めた上で、移行を検証してみることが非常に重要です。ナレッジだけをベースに検討すると思わぬ落とし穴にはまってしまう可能性が高くなります。

　まずは小さなアプリケーションから移行にチャレンジして、自分の体験として理解した上で詳細なアプリケーション移行の戦略を検討することをお勧めします。

　次回は、モダナイゼーションの詳細について解説する予定です。

筆者紹介

鈴木友宏

NTTデータ先端技術株式会社

Microsoft MVP for Developer Technologies