移植計画を作成する

2024-01-09

Visual Studio .NET Upgrade Assistant を使用して、.NET Framework コードを最新の .NET バージョンに更新することをお勧めします。詳細については、ブログ「Visual Studio を使用した .NET プロジェクトのアップグレード」を参照してください。

重要

.NET アップグレードアシスタントツールを使用したバイナリ分析を優先して、API ポートが非推奨になりました。 API ポートのバックエンドサービスがシャットダウンされているため、ツールを使うにはオフラインで使う必要があります。詳細については、.NET API ポートの README を参照してください。

コードにすぐ着手する前に、推奨される移行前の手順を実行します。この記事では、発生する可能性のある問題の詳細について説明し、最適なアプローチを決定できるようにします。

コードを移植する

続行する前に、コードの移植に関する前提条件に従っていることを確認します。最適な方法を決定し、コードの移植を開始できるようにします。

主にコンパイラを使用して対処する

このアプローチは、小さなプロジェクト、つまり多くの .NET Framework API を使用しないプロジェクトに適しています。このアプローチは単純です。

必要に応じて、プロジェクトで ApiPort を実行します。 ApiPort を実行すると、レポートから対応が必要となる問題についての情報を得られます。
すべてのコードを新しい .NET プロジェクトにコピーします。
移植性に関するレポート (生成されている場合) を参照しながら、プロジェクトが完全にコンパイルされるまでコンパイラエラーを解決します。

このコード中心のアプローチは、構造化されていませんが、多くの場合に問題を迅速に解決します。特に、データモデルのみが含まれるプロジェクトにはこのアプローチが最適です。

移植性の問題が解決されるまで .NET Framework を使い続ける

このアプローチは、すべてのプロセスでコンパイルできるコードを作成したい場合にお勧めです。アプローチは次のとおりです。

プロジェクトで ApiPort を実行します。
移植可能な別の API を使用して問題に対処します。
直接の代替方法を使用できない領域をすべて書き留めます。
新しい .NET プロジェクトにコピーしても問題ないことが確認できるまで、移植するすべてのプロジェクトに対して前の手順を繰り返します。
コードを新しい .NET プロジェクトにコピーします。
直接の代替手段がないと書き留めた問題に対処します。

この慎重なアプローチは、コンパイラエラーに対処するだけの方法よりも体系的ですが、それでも比較的コード中心であり、コンパイルできるコードが常にあるという利点があります。別の API を使用するだけでは解決できなかった問題を解決する方法は、大きく異なります。プロジェクトによっては、次のアプローチのように、より包括的な計画を開発する必要があります。

包括的な計画を新たに作成する

このアプローチは、.NET をサポートするために、コードの再構築や特定範囲の完全な書き換えが必要になる可能性があるような、大規模で複雑なプロジェクトにお勧めです。アプローチは次のとおりです。

プロジェクトで ApiPort を実行します。
移植できない性質のものが使用されている箇所と、それが移植性全体に与える影響を把握します。
- 種類の性質を理解します。数は少なくても使用頻度は高いですか。数は多くても使用頻度は低いですか。コードで集中して使用されていますか、それともあちこちで使用されていますか。
- 移植できないコードの分離は簡単で、効果的に処理できますか。
- コードをリファクタリングする必要はありますか。
- 移植可能ではない種類の場合、同じ作業を実行できる代替 API はありますか。たとえば、WebClient クラスを使用している場合は、代わりに HttpClient クラスを使用できます。
- 一時的な置き換えでない場合でも、作業を完了させるのに使用できる、移植可能な API が別にありますか。たとえば、XmlSchema を使用して XML を解析しているが、XML スキーマ検出が不要な場合、API に依存する代わりに、System.Xml.Linq API を使用して解析を独自に実装できます。
移植が困難なアセンブリがある場合、.NET Framework を今すぐ止める価値はあるでしょうか。考慮事項をいくつか以下に示します。
- .NET Framework または Windows 固有の機能への依存度が高いために、.NET との互換性がない機能がライブラリにあるとします。現時点ではその機能をあきらめ、機能を移植できるリソースが利用できるようになるまで、機能の少ない一時的な .NET バージョンのライブラリをリリースするのがよいでしょうか。
- リファクタリングが有効でしょうか。
使用できない .NET Framework API の代わりになる実装を開発することは理にかなっていますか。

.NET Framework の参照ソースのコードのコピー、変更、および使用も検討できます。この参照ソースコードは MIT ライセンスの下で使用が許可されているため、このソースをコードの基盤として、かなり自由に使用できます。ただし、コードには Microsoft への帰属を適切に示してください。
プロジェクトごとにこのプロセスを繰り返します。

コードベースのサイズによっては、分析フェーズに時間がかかる場合があります。このフェーズに時間を割き、必要な変更の範囲を完全に把握してから計画を立てることで、結果的に多くの時間を節約できます。特に、コードベースが複雑な場合には有効です。

コードベースの大幅な変更が必要な計画になる可能性がありますが、ターゲット設定は .NET Framework 4.7.2 です。これは前のアプローチよりも体系化されたバージョンです。計画の実施方法は、コードベースによって異なります。

混合アプローチ

多くの場合は、プロジェクトごとに、前述のアプローチを混合して利用します。自分とコードベースにとって最も有用な処理を実行します。

テストを移植する

コードを移植したときにすべての機能が動作することを確認するには、コードを .NET に移植してテストすることをお勧めします。このテストを行うには、.NET 用のテストを構築して実行するためのテストフレームワークを使用する必要があります。現在のところ、次の 3 つの選択肢があります。

推奨される方法

最終的に、移植作業は .NET Framework コードの構成内容に大きく左右されます。コードを移植するのに良い方法は、コードの基本コンポーネントであるライブラリの "ベース" から始めることです。ベースは、その他すべてが直接または間接的に使用するデータモデル、または他の基本クラスやメソッドの場合があります。

移植対象のライブラリのレイヤーをテストするテストプロジェクトを移植します。
ライブラリのベースを新しい .NET プロジェクトにコピーし、サポートする .NET Standard のバージョンを選択します。
必要に応じてコードを変更し、コンパイルします。多くの場合、NuGet パッケージの依存関係を csproj ファイルに追加する必要があります。
テストを実行し、必要な調整を行います。
次のコードレイヤーを選択して移植し、前の手順を繰り返します。

ライブラリのベースから開始してベースから外側に向かい、必要に応じて各レイヤーをテストする場合、移植は、問題が一度でコードの 1 レイヤーに分離される体系的なプロセスになります。