.NET 8は、間もなくリリースされる長期サポートバージョン（LTS）です。.NET 7は2024年5月14日にサポートが終了し、前の長期サポートバージョンである.NET 6も2024年11月12日にサポートが終了するため、.NET 8のリリースと共に多くのアップグレードが行われるでしょう。
では、なぜアップグレードするのでしょうか。実際、プログラマーにとってはアップグレードは煩わしいものです。問題なく使っているのに、なぜする必要があるのでしょうか。実際、セキュリティ部門が要求しない限りアップグレードする必要はありません。セキュリティ部門がない場合も、また、セキュリティ脆弱性に関する心配がない場合も、サービスがなくても問題ない場合も、アップグレードする必要はありません。機能しているプログラムが最良のプログラムですから。
では、アップグレードが必須の場合、何に注意すべきでしょうか。以下は、私が個人的に重要だと思うポイントです。
まず、現在のバージョンと最新バージョンの違いを確認することが重要です。.NET公式は、バージョンの互換性の違いに関するウェブサイトを提供していますので、参考にできます。例えば、現在のバージョンが.NET 6で、.NET 8にアップグレードする場合、まず.NET 6と.NET 7の違いを確認し、次に.NET 7と.NET 8の違いを確認します。そして、どの技術点が変更されたのかを総合的に考慮し、一度に修正を適用します。.NETバージョンの違いに関するウェブサイトのURLは以下の通りです：
https://learn.microsoft.com/zh-cn/dotnet/core/compatibility/library-change-rules。
次に、サードパーティのライブラリを調査します。サードパーティのライブラリは、.NET公式ほど親切に互換性文書を提供していないかもしれません。そのため、テストを通じて影響範囲を確認する必要があります。時には、官公庁が新しいバージョンを要求しているサードパーティのライブラリが遅れることがあります。その場合、同じ機能を持つ別のサードパーティのライブラリに切り替えるか、耐え忍んで待つ必要があります。
アップグレードの際は、将来廃止されたり、発展しないライブラリを事前に変更することが最善です。これにより、複数回のアップグレードを避けることができます。また、アップグレード後の官公庁ライブラリやサードパーティのライブラリは、機能の最適化や拡張をもたらし、これを利用して自身のサービスの性能や可用性を向上させることができます。
アップグレードは苦痛です。コードの修正だけでなく、リスクも伴います。そのため、アップグレード後のサービスを新しいプロジェクトとして扱い、プロジェクトのオンライン化プロセスを再度行うことが最善です。例えば、SLAを再調整します。ない場合は、少なくとも機能テスト、パフォーマンステスト、セキュリティチェックを再度行い、アップグレード後のアプリケーションに問題がないことを確認します。
(Translated by GPT)