Share via

Host bestimmt RID-spezifische Ressourcen

  • Artikel

Beim Ausführen einer Anwendung mit Runtimebezeichner-(RID)-spezifischen Ressourcen bestimmt der Host, welche Ressourcen für die Plattform relevant sind, auf der er ausgeführt wird. Dies gilt sowohl für die Anwendung selbst als auch für die von AssemblyDependencyResolver verwendete Auflösungslogik.

Zuvor hat der Host versucht, den RID zur Laufzeit zu berechnen und dann das RID-Diagramm zu lesen, um zu ermitteln, welche RID-spezifischen Ressourcen mit dem berechneten RID übereinstimmten oder kompatibel waren. Jetzt berechnet das Standardverhalten den RID nicht und verwendet auch nicht das RID-Diagramm. Stattdessen nutzt der Host eine bekannte Liste von RIDs, die darauf basiert, wie die Laufzeitumgebung selbst erstellt wurde.

Vorheriges Verhalten

Zuvor lief der Prozess für die Auswahl von RID-spezifischen Ressourcen wie folgt ab:

  1. Das RID-Diagramm wurde aus der Datei .deps.json des Stammframeworks (Microsoft.NetCore.App) gelesen.
  2. Die aktuelle RID zur Laufzeit wurde berechnet, und es wurde versucht, einen Eintrag dafür im RID-Diagramm zu finden. Wenn keiner vorhanden war, wurde nach einem Fallback-RID (zur Kompilierzeit in den Host integriert) gesucht.
  3. Es wurde ab dem Eintrag im RID-Diagramm nach Ressourcen gesucht, die diesem RID entsprechen.
  4. Es wurde mit der Liste der RIDs im RID-Diagrammeintrag fortgefahren, bis eine Ressourcenübereinstimmung gefunden wurde oder die Liste endete.

Wenn das RID-Diagramm den berechneten RID oder den Fallback RID nicht enthielt, wurden RID-Ressourcen nicht ordnungsgemäß aufgelöst.

Neues Verhalten

Standardmäßig basiert der Prozess jetzt nicht mehr auf dem RID-Diagramm. Stattdessen wird basierend auf der Erstellung des Hosts nach einer bekannten Gruppe portabler RIDs gesucht. Beispiel:

Linux

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

Windows

  • win-x64
  • win
  • any

macOS

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

Für nicht portierbare Builds des Hosts oder der Laufzeit kann der Build auch einen nicht portierbaren RID festlegen, der zuerst aktiviert wird.

Eingeführt in Version

.NET 8 Vorschauversion 5

Typ des Breaking Changes

Diese Änderung kann sich auf die Binärkompatibilität auswirken und ist außerdem ein Behavior Change.

Grund für die Änderung

Das RID-Diagramm war aufwändig in der Pflege und im Verständnis und erforderte, dass .NET selbst auf anfällige Art und Weise distributionsabhängig ist. Das .NET-Team und die Community verbringen einen nicht unerheblichen Teil ihrer Zeit mit der Aktualisierung des Diagramms und der Rückportierung solcher Aktualisierungen in frühere Versionen. Das langfristige Ziel ist es, das RID-Diagramm nicht mehr zu aktualisieren, es nicht mehr zu lesen und es schließlich zu entfernen. Dieser Breaking Change ist ein Schritt in Richtung dieses Ziels.

Verwenden Sie portable RIDs, z. B. linux, linux-musl, osx und win. Für spezielle Anwendungsfälle können Sie APIs wie NativeLibrary.SetDllImportResolver(Assembly, DllImportResolver) oder AssemblyLoadContext.ResolvingUnmanagedDll für benutzerdefinierte Ladelogik verwenden.

Wenn Sie auf das vorherige Verhalten zurücksetzen müssen, legen Sie den Abwärtskompatibilitätsschalter System.Runtime.Loader.UseRidGraph in Ihrer Datei runtimeconfig.json auf true fest. Durch Festlegen des Schalters auf true wird der Host angewiesen, das vorherige Verhalten beim Lesen des RID-Diagramms anzuwenden. Alternativ können Sie die MSBuild-Eigenschaft UseRidGraph in Ihrer Projektdatei auf true festlegen. Beispiel:

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

Betroffene APIs

Siehe auch