Partager via

Détection par défaut

L’instance AssemblyLoadContext.Default est chargée de localiser les dépendances d’un assembly. Cet article décrit la logique de détection de l’instance AssemblyLoadContext.Default .

Propriétés de détection configurées par l’hôte

Lorsque le runtime est démarré, l’hôte du runtime fournit un ensemble de propriétés de détection nommées qui configurent AssemblyLoadContext.Default les chemins de sonde.

Chaque propriété de détection est facultative. Si elle est présente, chaque propriété est une valeur de chaîne qui contient une liste délimitée de chemins absolus. Le délimiteur est « ; » sur Windows et « : » sur toutes les autres plateformes.

Nom de la propriété Description
TRUSTED_PLATFORM_ASSEMBLIES Liste des chemins de fichier d’assemblage de plateforme et d’application.
PLATFORM_RESOURCE_ROOTS Liste des chemins de répertoires pour rechercher des assemblies de ressources satellites.
NATIVE_DLL_SEARCH_DIRECTORIES Liste des chemins d’accès au répertoire pour rechercher des bibliothèques non managées (natives).
APP_PATHS Liste des chemins d’accès de répertoire pour rechercher des assemblages managés.

Comment les propriétés sont-elles remplies ?

Il existe deux scénarios principaux pour remplir les propriétés selon que le <fichier myapp>.deps.json existe.

  • Lorsque le fichier *.deps.json est présent, il est analysé pour remplir les propriétés de détection.
  • Lorsque le fichier *.deps.json n’est pas présent, le répertoire de l’application est supposé contenir toutes les dépendances. Le contenu du répertoire est utilisé pour remplir les propriétés de détection.

En outre, les fichiers *.deps.json pour toutes les infrastructures référencées sont analysés de la même façon.

La variable DOTNET_ADDITIONAL_DEPS d’environnement peut être utilisée pour ajouter des dépendances supplémentaires. dotnet.exe contient également un paramètre facultatif --additional-deps pour définir cette valeur au démarrage de l’application.

Note

La DOTNET_ADDITIONAL_DEPS variable d’environnement et l’option de ligne de commande s’appliquent uniquement aux --additional-deps. Ces options sont ignorées pour les applications autonomes. Pour plus d’informations, consultez Déploiements dépendant du framework et autonomes.

La APP_PATHS propriété n’est pas remplie par défaut et est omise pour la plupart des applications.

La liste de tous les fichiers *.deps.json utilisés par l’application est accessible via System.AppContext.GetData("APP_CONTEXT_DEPS_FILES").

Comment voir les propriétés de détection à partir du code managé ?

Chaque propriété est disponible en appelant la AppContext.GetData(String) fonction avec le nom de propriété du tableau ci-dessus.

Comment faire pour déboguer la construction des propriétés de sondage ?

L’hôte du runtime .NET Core génère des messages de trace utiles lorsque certaines variables d’environnement sont activées :

Variable d’environnement Description
DOTNET_HOST_TRACE=1 Active le suivi.
DOTNET_HOST_TRACEFILE=<path> Effectue le suivi vers un chemin d’accès de fichier plutôt que vers le stderr par défaut.
DOTNET_HOST_TRACE_VERBOSITY Définit le niveau de verbosité de 1 (le plus bas) à 4 (le plus élevé).

Pour plus d’informations, consultez DOTNET_HOST_TRACE variables d’environnement.

Sondage par défaut de l’assembly managé

Lors d’un sondage pour trouver un assembly managé, le AssemblyLoadContext.Default examine dans l’ordre :

  • Fichiers correspondant à AssemblyName.Name dans TRUSTED_PLATFORM_ASSEMBLIES (après suppression des extensions de fichier).
  • Fichiers d’assembly dans APP_PATHS utilisant des extensions de fichier courantes.

Sondage d’assembly satellite (ressource)

Pour rechercher un assembly satellite pour une culture spécifique, construisez un ensemble de chemins de fichier.

Pour chaque chemin d'accès dans PLATFORM_RESOURCE_ROOTS puis dans APP_PATHS, ajoutez la chaîne CultureInfo.Name, un séparateur de répertoires, la chaîne AssemblyName.Name et l'extension '.dll'.

Si un fichier correspondant existe, essayez de le charger et de le renvoyer.

Détection de bibliothèque non managée (native)

L'algorithme du runtime pour la détection de bibliothèques non gérées est identique sur toutes les plateformes. Toutefois, étant donné que la charge réelle de la bibliothèque non managée est effectuée par la plateforme sous-jacente, le comportement observé peut être légèrement différent.

  1. Vérifiez si le nom de la bibliothèque fourni représente un chemin absolu ou relatif.

  2. Si le nom représente un chemin absolu, utilisez le nom directement pour toutes les opérations suivantes. Sinon, utilisez le nom et créez des combinaisons définies par la plateforme à prendre en compte. Les combinaisons se composent de préfixes spécifiques à la plateforme (par exemple, lib) et/ou de suffixes (par exemple, , .dll, .dylibet .so). Cette liste n’est pas exhaustive et ne représente pas l’effort exact effectué sur chaque plateforme. C’est juste un exemple de ce qui est considéré. Pour plus d’informations, consultez le chargement de bibliothèque native.

  3. Le nom et, si le chemin d’accès est relatif, chaque combinaison, est ensuite utilisée dans les étapes suivantes. La première tentative de chargement réussie retourne immédiatement le descripteur à la bibliothèque chargée.

    • Ajoutez-le à chaque chemin fourni dans la propriété NATIVE_DLL_SEARCH_DIRECTORIES et essayez de charger.

    • Si DefaultDllImportSearchPathsAttribute n’est pas défini sur l’assembly appelant ou p/invoke est défini et inclut DllImportSearchPath.AssemblyDirectory, ajoutez le nom ou la combinaison au répertoire de l’assembly appelant et essayez de charger.

    • Utilisez-le directement pour charger la bibliothèque.

  4. Indiquez que la bibliothèque n’a pas pu être chargée.

  • Last updated on