Partager via

L’hôte détermine les ressources propres au RID

Lors de l’exécution d’une application avec des ressources spécifiques de l’identificateur de runtime (RID), l’hôte détermine les ressources pertinentes pour la plateforme sur laquelle elle s’exécute. Cela s’applique à la fois à l’application elle-même et à la logique de résolution utilisée par AssemblyDependencyResolver.

Auparavant, l’hôte a essayé de calculer le RID au moment de l’exécution, puis de lire le graphique RID pour déterminer quelles ressources spécifiques au RID correspondaient ou étaient compatibles avec le RID calculé. À présent, le comportement par défaut ne calcule pas le RID ou n’utilise pas le graphique RID. Au lieu de cela, l’hôte s’appuie sur une liste connue de RID en fonction de la façon dont le runtime lui-même a été généré.

Comportement précédent

Auparavant, le processus de sélection des ressources spécifiques au RID était le suivant :

  1. Lisez le graphique RID à partir du fichier .deps.json de l’infrastructure racine (Microsoft.NetCore.App).
  2. Calculez le RID actuel au moment de l’exécution et essayez de trouver une entrée pour celle-ci dans le graphique RID. S’il n’existe pas, recherchez un RID de secours (intégré à l’hôte au moment de la compilation).
  3. À partir de l’entrée trouvée dans le graphique RID, recherchez les ressources correspondant à ce RID.
  4. Poursuivez la liste des RID dans l’entrée de graphique RID jusqu’à ce qu’une correspondance de ressource soit trouvée ou que la liste se termine.

Si le graphique RID n’a pas le RID calculé ou le RID de repli, les ressources RID n’ont pas été correctement traitées.

Nouveau comportement

Par défaut, le processus ne s’appuie plus sur le graphique RID. Au lieu de cela, il vérifie un ensemble connu de RID portables en fonction de la façon dont l'hôte a été construit. Par exemple:

Linux

  • linux-x64
  • Linux
  • unix-x64
  • Unix
  • quelconque

Fenêtres

  • win-x64
  • gagner
  • quelconque

macOS

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

Pour les builds non portables de l’hôte ou du runtime, la build peut également définir un RID non portable vérifié en premier.

Version introduite

.NET 8 Preview 5

Type de changement cassant

Cette modification peut affecter la compatibilité binaire et est également un changement comportemental.

Raison de la modification

Le graphique RID a été coûteux à maintenir et à comprendre, exigeant que .NET lui-même soit distro-conscient d’une manière fragile. L’équipe .NET et la communauté passent un certain temps à mettre à jour le graphique et à rétroporter ces mises à jour vers les versions précédentes. L’objectif à long terme est d’arrêter la mise à jour du graphique RID, d’arrêter de le lire et de le supprimer. Ce changement majeur est un pas vers cet objectif.

Utilisez des RID portables, par exemple, linux, linux-musl, osxet win. Pour les cas d’usage spécialisés, vous pouvez utiliser des API telles que NativeLibrary.SetDllImportResolver(Assembly, DllImportResolver) ou AssemblyLoadContext.ResolvingUnmanagedDll pour une logique de chargement personnalisée.

Si vous devez revenir au comportement précédent, définissez le commutateur de compatibilité descendante System.Runtime.Loader.UseRidGraphtrue dans votre fichier runtimeconfig.json. Paramétrer le commutateur sur true indique à l’hôte d’utiliser le comportement antérieur pour la lecture du graphique RID. Vous pouvez également définir la propriété MSBuild UseRidGraph sur true dans votre fichier projet. Par exemple

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

API affectées

Voir aussi

  • Last updated on