Ignite Microsoft は、開発者が .NET Framework アプリケーションを .NET 5.0 に移植できるようにするための新しいアップグレード アシスタントをプレビューしましたが、完全なソリューションにはまだ程遠い状況です。
Microsoft が .NET Framework をフォークしてオープン ソースの .NET Core (現在は .NET として知られています) になったとき、既存の .NET Framework アプリケーションに簡単にアップグレードできるパスがないという問題が発生しました。
問題は些細なものから、Webフォームフレームワーク（.NETの元祖Webアプリケーションフレームワーク）全体が欠けているといった致命的なものまで多岐にわたります。既存の.NET Frameworkアプリケーションをサポートする必要性は、古くなるにつれてますます厄介なものになるでしょう。
期待の持てる緑色の「完了」ステートメントが連続して表示され、.NET Frameworkアプリケーションの移行が成功するという希望が湧きました。
.NET Framework は引き続きサポートされています。バージョン 4.5.2 以降は Windows のコンポーネントとして定義されているため、Windows のサポートライフサイクルに従います。古いバージョンの .NET Framework では問題が多くなりますが、4.x へのアップグレードは .NET Core への移植よりも簡単です。
しかし、Microsoftは、2019年4月にリリースされた.NET Framework 4.8が最後のメジャーバージョンであり、「今後の投資はすべて.NET Coreに集中する」と述べています。コンテナサポートの強化、Linuxとの互換性、新機能やパフォーマンス向上のメリットはすべて、.NET Core / .NET 5.0以降をターゲットとするアプリケーションに提供されることになります。
変換されたアプリケーションのビルドに失敗しました。実行する前に調整が必要であり、その後テストする必要があります。
では、レガシー アプリケーションを移植するにはどうすればよいでしょうか?
以前より簡単になりました。今では Windows Forms や Windows Presentation Foundations のデスクトップ アプリケーションも .NET Core で実行されるようになりました (もちろん Windows 上のみですが)。
純粋なC#コードは移植が容易ですが、依存関係やライブラリの違いが問題となり、解決が困難な場合があります。ユニットテストで十分にカバーされたアプリケーションは、予期しない結果を引き起こす可能性のある動作の違いを発見できる可能性が高く、より安全に移植できます。
堅牢なアプローチとしては、新しいプロジェクトを立ち上げ、既存のコードを少しずつコピーしていくのが考えられますが、これは時間がかかります。プロジェクトを移行するためのツールを実行するだけではどうでしょうか？これは良いアイデアですが、移植性アナライザーは存在するものの、Microsoftにはこれまで存在していませんでした。
Amazon Web Servicesはこのギャップに気づき、独自のオープンソース移植アシスタントをリリースしましたが、問題がないわけではありません。また、MicrosoftのエンジニアであるSrivatsn Narayanan氏の成果に基づいたtry-convertツールも存在しますが、これには「このツールは一切サポートされていません。このツールで発生した問題の修正は、誰も責任を負うものではありません」という警告が付いています。
Igniteで、Microsoftはtry-convertをベースにした新しいツール「.NET Upgrade Assistant」を発表しました。ただし、プロジェクトリーダーのキャシー・サリバン氏は、プロジェクト紹介記事の中でサポートの制限について触れていません。このツールはプレビュー版で、GitHubでオープンソース化されています。
「このツールは、新しい SDK スタイルのプロジェクト形式へのアップグレード、.NET 5 への再ターゲット、NuGet パッケージの依存関係の更新など、通常は手動で行うアップグレード プロセスの多くのタスクを自動化します」と Sullivan 氏は述べています。
このツールは、ASP.NET MVC、Windows Forms、WPFアプリケーションで動作するように設計されています。Optimizelyというサードパーティが、同社の「大規模なASP.NETアプリケーションポートフォリオ」をアップグレードしたいと考えていたため、このツールの開発に協力したと彼女は付け加えました。
それはどれくらいうまく機能しますか?
実際に試してみました。インストールは簡単で、dotnet tool コマンドラインユーティリティを使って、まず try-convert をインストールし、次にアップグレードアシスタントをインストールしました。最初の試みとして、Visual Basic で構築された古い Windows フォームアプリケーションを選択しました。しかし、うまくいきませんでした。「Visual Basic is not supported。」
次に、Azure AD認証を使用する小規模なASP.NET MVCアプリケーションを作成しました。アップグレードアシスタントは、プロジェクトの変換、ターゲットフレームワーク（TFM）の更新、C#ソースへの修正の適用など、いくつかの手順をスムーズに実行しました。
結果を読み込んでビルドしようとするまで、すべて正常に見えました。「Consider app.config remapping of assembly "Microsoft.Data.Services.Client … Choosing "Microsoft.Data.Services.Client, Version=5.8.4.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" arbitrarily」と Visual Studio は言いました。
その後、ビルドはいくつかのエラーで失敗し、エントリポイントが見つからず、次のように宣言されました: " The name HttpUtility does not exist in the current context。
こうしたことは予想されることであり、サリバン氏は「こうした変更にはアプリとその機能の意図に関する知識が必要となるため、手動による変更は依然として必要になる」と指摘した。
問題は、DIYアプローチと比べて移植が加速するかどうかです。私たちのケースでは、答えが出るまでにはもう少し作業が必要そうです。開発者がプロジェクトの移植に取り組むと、ライブラリを新しいバージョンにアップグレードすることが一般的であり、そのためには移植に必要な範囲を超えたコード変更が必要になることがよくあります。
これは簡単に大きな労力を必要とする作業になる可能性があり、予期しない出力のリスクも伴うため、多くの組織では今後も長期間にわたり、従来の .NET Framework アプリケーションが引き続き実行され続けることになります。®
