次の方法で共有

ASP.NET から ASP.NET Core への増分移行を開始する方法

Important

開始する前に: この記事では、 ASP.NET Core 移行の概要を確認していることを前提としています。 まだ読んでいない場合は、そこから始めて、増分移行の概念、アプローチ、利点を理解してください。

大規模な移行の場合は、元の .NET Framework アプリにプロキシする ASP.NET Core アプリを設定することをお勧めします。 新しいプロキシが有効なアプリを次の図に示します。

ルートの移行を開始する

この記事では、このアプローチを理解した後に増分移行を進める実用的な手順について説明します。

Prerequisites

増分移行を開始する前に、次のことを確認してください。

  1. 概要を読む: ASP.NET から ASP.NET Core への段階的移行
  2. 稼働中のASP.NET Framework アプリケーションを移行する
  3. Visual Studio 2022 と最新の更新プログラム
  4. インストールされている .NET 8 以降の SDK
  5. アプリケーションの依存関係 とサード パーティ製ライブラリの理解

移行手順の概要

増分移行プロセスは、次の主要な手順に従います。

  1. コア プロジェクト ASP.NET 設定する
  2. 技術的負債の修復
  3. 横断的な懸念事項を特定して対処する
  4. サポート ライブラリのアップグレード

ASP.NET Core プロジェクトをセットアップする

最初の手順では、プロキシとして機能する新しい ASP.NET Core アプリケーションを作成します。

次の操作を行います。

  • 既存の ASP.NET Framework アプリと共に新しい ASP.NET Core プロジェクトを作成する
  • YARP (別のリバースプロキシ) を使用して元のアプリケーションへの要求をプロキシするように構成する。
  • 増分移行の基本的なインフラストラクチャを設定する

Detailed instructions:

技術的負債の修復

この手順を実行する場合: サポートライブラリをアップグレードする前に、移行プロセスを複雑にする可能性のある技術的負債に対処してください。

サポート ライブラリのアップグレードを開始する前に、移行プロセスを妨げる可能性のある技術的負債をクリーンアップすることが重要です。 この手順は、スムーズなアップグレード エクスペリエンスを確保するために最初に完了する必要があります。

パッケージの依存関係の更新

NuGet パッケージを最新の互換性のあるバージョンに確認して更新します。

  1. 既存のパッケージの監査: dotnet CLI が ASP.NET Framework アプリケーションで機能しないため、Visual Studio の NuGet パッケージ マネージャーを使用する
  2. パッケージを段階的に更新する: 互換性の問題を回避するためにパッケージを一度に 1 つずつ更新する
  3. 各更新後のテスト: 各パッケージの更新後もアプリケーションが正しく機能することを確認する
  4. 破壊的変更への対処: 一部のパッケージ更新によって対処を要する破壊的変更が導入されることがあります

ビルド ツールの最新化

ビルド ツールとプロジェクト構成を更新します。

  1. 更新ツール: 最新バージョンの MSBuild/Visual Studio を使用していることを確認する
  2. 依存関係のために PackageReference に移行する: Web アプリケーション プロジェクトにまだ参加していない場合は、 packages.config から PackageReference 形式に移行することを検討してください
  3. 未使用の参照をクリーンアップする: 未使用のアセンブリ参照または NuGet パッケージを削除する
  4. SDK スタイルのプロジェクト ファイルに移行する: 既存のプロジェクト ファイルを最新の SDK スタイルの形式に変換します。 これは、最新の .NET プロジェクトとの互換性のために不可欠であり、より優れたツールサポートを提供します
  5. ビルド スクリプトの更新: カスタム ビルド スクリプトまたは CI/CD 構成を確認して更新する

コード品質の問題に対処する

移行が複雑になる可能性がある既知のコード品質の問題を修正します。

  1. コンパイラの警告を修正する: コンパイラの警告 、特に非推奨の API に関連する警告に対処する
  2. デッド コードの削除: 未使用のクラス、メソッド、およびその他のコード要素をクリーンアップする
  3. 非推奨の API の使用を更新する: 非推奨の API の使用を、可能な限り最新の同等のものに置き換えます

この準備作業により、ライブラリのアップグレード プロセスがはるかにスムーズになり、移行中に複雑な問題が発生する可能性が低くなります。

横断的な懸念事項を特定して対処する

この手順を実行する場合: 技術的負債を修復しながら、サポート ライブラリをアップグレードする前に、アプリケーション全体に影響する横断的な懸念事項を特定して構成します。

横断的な懸念事項は、認証、セッション管理、ログ記録、キャッシュなど、複数のレイヤーまたはコンポーネントにまたがるアプリケーションの側面です。 これらは移行プロセスの早い段階で対処する必要があります。これは、ASP.NET Framework および ASP.NET Core アプリケーションが増分移行中に状態を通信および共有する方法に影響するためです。

次のセクションでは、最も一般的な横断的な問題について説明します。 アプリケーションに適用するもののみを構成します。

セッション サポートの構成

次の場合に構成します。 ASP.NET Framework アプリケーションはセッション状態を使用します。

ガイダンスについては、一般的な セッション移行のドキュメント を参照してください。

セッションは、ASP.NET Core の機能と名前を共有する ASP.NET の一般的な機能ですが、API は大きく異なります。 セッション状態を使用するライブラリをアップグレードする場合は、セッション サポートを構成する必要があります。 アプリケーション間でセッション状態の共有を有効にする方法の詳細なガイダンスについては、 リモート セッションのサポート に関するドキュメントを参照してください。

Authentication Configuration

次の場合に構成します。 ASP.NET Framework アプリケーションでは認証が使用されており、古いアプリケーションと新しいアプリケーションの間で認証状態を共有する必要があります。

ガイダンスについては、一般的な 認証移行に関するドキュメント を参照してください。

System.Web アダプターのリモート認証機能を使用して、元の ASP.NET アプリと新しい ASP.NET Core アプリの間で認証を共有できます。 この機能により、ASP.NET Core アプリは、認証を元の ASP.NET アプリに延期できます。 詳細については、 リモート認証 に関するドキュメントを参照してください。

考慮すべきその他の横断的な懸念事項

アプリケーションによっては、次の対処が必要になる場合もあります。

  • ログ記録: 両方のアプリケーション間で一貫したログ記録を確保します。 共有ログ プロバイダーを使用するか、ログが正しく集計されていることを確認することを検討してください。
  • キャッシュ: アプリケーションでキャッシュ (メモリ内、分散、または出力キャッシュ) を使用する場合は、アプリケーション間のキャッシュ整合性を維持する方法を計画します。
  • エラー処理: ASP.NET Framework アプリケーションと ASP.NET Core アプリケーションの両方で、一貫したエラー処理とレポートを確立します。
  • 構成管理: 2 つのアプリケーション間で構成設定を共有または管理する方法を計画します。
  • 正常性の監視: 移行プロセス中に両方のアプリケーションの監視と正常性チェックを設定します。
  • 依存関係の挿入: ASP.NET Framework アプリで DI コンテナーを使用する場合は、ASP.NET Core の組み込み DI コンテナーへの移行を計画します。

サポート ライブラリのアップグレード

この手順を実行する場合: ビジネス ロジックを含むクラス ライブラリに依存する特定のルートを移行する必要がある場合にのみ、古いアプリケーションと新しいアプリケーション間で共有する必要があります。

Note

増分アプローチ: 増分移行プロセスでは、すべてのサポート ライブラリを一度にアップグレードする必要はありません。 アップグレードする必要があるのは、現在移行している特定のルートに必要なライブラリだけです。 これにより、より小さく、より管理しやすい部分で移行に取り組むことができます。

ライブラリのアップグレード プロセス

Important

サポート ライブラリは、 後順序の深さ優先検索順序でアップグレードする必要があります。 This means:

  1. リーフ依存関係から始める: ソリューション内の他のライブラリに依存関係がないライブラリから始める
  2. 依存関係ツリーを介して上方向に作業する: すべての依存関係が正常にアップグレードされた後にのみライブラリをアップグレードする
  3. メイン アプリケーションで終了する: メイン ASP.NET Framework アプリケーションは、変更する最後の項目にする必要があります

この順序付けは、次の理由で不可欠です。

  • これにより、ライブラリをアップグレードするときに、そのすべての依存関係に既に互換性があることを確認します。
  • アップグレード プロセス中に循環依存関係の問題が発生するのを防ぎます
  • 依存するライブラリに移動する前に、各ライブラリを個別にテストできます

注: この順序に従う必要があるのは、ソリューション全体ではなく、現在移行しているルートで必要なライブラリのサブセットに対してのみ行ってください。

各ライブラリのアップグレード プロセス:

ソリューションにサポート ライブラリがあり、移行するルートに使用する必要がある場合は、可能であれば.NET Standard 2.0 にアップグレードする必要があります。 アップグレード アシスタント は、このための優れたツールです。 ライブラリで .NET Standard をターゲットにできない場合は、元のプロジェクトの .NET Framework ターゲットと共に、または元のプロジェクトと共に新しいプロジェクトで .NET 8 以降をターゲットにすることができます。

System.Web アダプターは、クラス ライブラリでのHttpContextの使用をサポートするために、これらのライブラリで使用できます。 ライブラリで HttpContext の使用を有効にするには、

  1. プロジェクト ファイル内の System.Web への参照を削除する
  2. Microsoft.AspNetCore.SystemWebAdapters パッケージを追加する
  3. マルチターゲットを有効にして .NET 8 ターゲット以降を追加するか、プロジェクトを .NET Standard 2.0 に変換します。

この手順では、ソリューションの構造と移行するルートに応じて、多くのプロジェクトの変更が必要になる場合があります。 アップグレード アシスタントは、プロセスの複数の手順を変更して自動化する必要があるものを特定するのに役立ちます。

Next Steps

上記のセットアップとライブラリのアップグレード手順が完了したら、次の手順を実行します。

  1. 小規模から始める: まず、単純でステートレスなエンドポイントを移行します
  2. 十分にテストする: 移行された各コンポーネントが両方の環境で正しく動作することを確認する
  3. パフォーマンスの監視: プロキシのセットアップによるパフォーマンスへの影響を監視する
  4. 反復処理: 移行が完了するまでコンポーネントの増分移行を続行する
  • Last updated on