Partager via

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

  • Article

Lors de l’exécution d’une application avec des ressources spécifiques à l’identificateur d’exécution (RID), l’hôte détermine quelles ressources sont pertinentes pour la plateforme sur laquelle il 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 essayait de calculer le RID au moment de l’exécution, puis lisait le graphe RID pour déterminer quelles ressources propres au RID correspondaient au RID calculé ou étaient compatibles avec lui. À présent, le comportement par défaut ne calcule pas le RID et n’utilise pas le graphe RID. Au lieu de cela, l’hôte s’appuie sur une liste connue de RID basée sur la manière dont le runtime lui-même a été créé.

Comportement précédent

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

  1. Lire le graphe RID à partir du fichier .deps.json du framework racine (Microsoft.NetCore.App)
  2. Calculer le RID actuel au moment de l’exécution et tentative de trouver une entrée pour celui-ci dans le graphe RID. S’il n’existe pas, vérifier s’il existe un RID de secours (intégré à l’hôte au moment de la compilation)
  3. À partir de l’entrée trouvée dans le graphe RID, rechercher les ressources correspondant à ce RID
  4. Continuer vers le bas de la liste des RID dans l’entrée du graphe RID jusqu’à ce qu’une correspondance de ressource soit trouvée ou que la liste se termine

Si le graphe RID n’avait pas le RID calculé ou le RID de secours, les ressources RID n’ont pas été correctement résolues.

Nouveau comportement

Par défaut, le processus ne repose plus sur le graphe RID. Au lieu de cela, il recherche un ensemble connu de RID portables en fonction de la façon dont l’hôte a été créé. Par exemple :

Linux

  • linux-x64
  • linux
  • unix-x64
  • unix
  • n'importe laquelle

Windows

  • win-x64
  • win
  • n'importe laquelle

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 qui est vérifié en premier.

Version introduite

.NET 8 Preview 5

Type de changement cassant

Cette modification peut affecter la compatibilité binaire, et constitue également un changement de comportement.

Raison du changement

La maintenance et la compréhension du graphe RID étaient coûteuses, exigeant que .NET lui-même soit sensible à la distribution de manière fragile. L’équipe .NET et la communauté consacrent un temps non négligeable à la mise à jour du graphe et au rétroportage de ces mises à jour vers les versions précédentes. L’objectif à long terme est d’arrêter de mettre à jour du graphe RID, d’arrêter de le lire, puis de le supprimer. Ce changement cassant est un pas vers cet objectif.

Utilisez des RID portables, par exemple linux, linux-musl, osx et 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.UseRidGraph sur true dans votre fichier runtimeconfig.json. La définition du commutateur sur true indique à l’hôte qu’il doit utiliser le comportement précédent de lecture du graphe 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