次の方法で共有

ホストが RID 固有の資産を決定する

  • [アーティクル]

ランタイム ID (RID) 固有の資産を使ってアプリケーションを実行すると、それが実行されているプラットフォームに関連する資産が、ホストによって決定されます。 これは、アプリケーション自体と、AssemblyDependencyResolver によって使われる解決ロジックの両方に適用されます。

以前のホストは、実行時に RID を計算してから、RID グラフを読み取り、一致する RID 固有の資産、または計算された RID と互換性のあるものを、特定しようとしました。 現在の既定の動作では、RID の計算や、RID グラフの使用は行われません。 代わりに、ホストは、ランタイム自体が構築された方法に基づく、既知の RID の一覧に依存します。

以前の動作

以前は、次のようなプロセスで RID 固有の資産が選ばれていました。

  1. ルート フレームワークの .deps.json ファイルから RID グラフを読み取ります (Microsoft.NetCore.App)。
  2. 実行時に現在の RID を計算し、RID グラフでそのエントリの検索を試みます。 存在しない場合は、フォールバック RID を調べます (コンパイル時にホストに組み込まれます)。
  3. RID グラフで見つかったエントリから始めて、その RID に一致する資産を探します。
  4. 一致する資産が見つかるか、リストが終了するまで、RID グラフ エントリの RID のリストの検索を続けます。

RID グラフに計算された RID またはフォールバック RID がない場合、RID 資産は正しく解決されませんでした。

新しい動作

既定では、このプロセスは RID グラフに依存しなくなりました。 代わりに、ホストの構築方法に基づく既知の移植可能な RID のセットを調べます。 次に例を示します。

Linux

  • linux-x64
  • linux
  • unix-x64
  • unix
  • any

Windows

  • win-x64
  • win
  • any

macOS

  • osx-x64
  • osx
  • unix-x64
  • unix

ホストまたはランタイムの移植不可能なビルドの場合、最初にチェックされる移植不可能な RID がビルドによって設定される場合もあります。

導入されたバージョン

.NET 8 Preview 5

破壊的変更の種類

この変更は、バイナリの互換性に影響を与える可能性があり、動作の変更でもあります。

変更理由

RID グラフは、保守と理解にコストがかかり、.NET 自体が脆弱な方法でディストリビューションに対応する必要がありました。 .NET チームとコミュニティは、グラフの更新と、以前のリリースへのこのような更新のバックポートに、多くの時間を費やしています。 長期的な目標は、RID グラフの更新を停止し、その読み取りを停止して、最終的にそれを削除することです。 この破壊的変更は、その目標に向けた一歩です。

ポータブル RID (linux、linux-musl、osx、win など) を使います。 特殊なユース ケースでは、NativeLibrary.SetDllImportResolver(Assembly, DllImportResolver) や AssemblyLoadContext.ResolvingUnmanagedDll などの API をカスタム読み込みロジックに使用できます。

以前の動作に戻す必要がある場合は、runtimeconfig.json ファイルで、下位互換性スイッチ System.Runtime.Loader.UseRidGraph を true に設定します。 スイッチを true に設定すると、以前の RID グラフを読み取る動作を使うようにホストに指示されます。 あるいは、プロジェクト ファイルで UseRidGraph MSBuild プロパティを true に設定することもできます。 次に例を示します。

<PropertyGroup>
  <UseRidGraph>true</UseRidGraph>
</PropertyGroup>

影響を受ける API

関連項目