Domaines d'application et assemblys
Cette rubrique décrit la relation entre les domaines d'application et les assemblys. Vous devez charger un assembly dans un domaine d'application avant de pouvoir exécuter le code qu'il contient. L'exécution d'une application standard entraîne le chargement de plusieurs assemblys dans un domaine d'application.
La façon dont un assembly est chargé détermine si son code compilé juste-à-temps (JIT) peut être partagé par plusieurs domaines d'application dans le processus, et si l'assembly peut être déchargé du processus.
Si un assembly est chargé comme indépendant du domaine, tous les domaines d'application qui partagent le même jeu d'autorisations de sécurité peuvent partager le même code compilé juste-à-temps, ce qui réduit la mémoire requise par l'application. Toutefois, l'assembly ne peut jamais être déchargé du processus.
Si un assembly n'est pas chargé comme indépendant du domaine, il doit être compilé juste-à-temps dans chaque domaine d'application dans lequel il est chargé. Toutefois, l'assembly peut être déchargé du processus via le déchargement de tous les domaines d'application dans lesquels il est chargé.
L'hôte de runtime détermine s'il convient de charger des assemblys comme indépendants du domaine lorsqu'il charge le runtime dans un processus. Pour les applications managées, appliquez l'attribut LoaderOptimizationAttribute à la méthode de point d'entrée pour le processus et spécifiez une valeur de l'énumération LoaderOptimization associée. Pour les applications non managées qui hébergent le Common Language Runtime, spécifiez l'indicateur approprié lorsque vous appelez la méthode CorBindToRuntimeEx, fonction.
Il existe trois options de chargement des assemblys indépendants du domaine :
SingleDomain ne charge aucun assembly comme indépendant du domaine, sauf Mscorlib, qui est toujours chargé comme indépendant du domaine. Ce paramètre est désigné par « domaine unique », car il est fréquemment utilisé lorsque l'hôte n'exécute qu'une seule application dans le processus.
MultiDomain charge tous les assemblys comme indépendants du domaine. Utilisez ce paramètre lorsque plusieurs domaines d'application figurent dans le processus et qu'ils exécutent tous le même code.
MultiDomainHost charge les assemblys avec nom fort comme indépendants du domaine s'ils ont été installés, ainsi que toutes leurs dépendances, dans le Global Assembly Cache. Les autres assemblys sont chargés et compilés juste-à-temps séparément pour chaque domaine d'application dans lequel ils sont chargés, et peuvent donc être déchargés du processus. Utilisez ce paramètre lors de l'exécution de plusieurs applications dans le même processus, ou si vous disposez d'un mélange d'assemblys partagés par de nombreux domaines d'application et d'assemblys qui doivent être déchargés du processus.
Le code compilé juste-à-temps ne peut pas être partagé pour les assemblys chargés dans le contexte de chargement, à l'aide de la méthode LoadFrom de la classe Assembly, ou chargés à partir d'images à l'aide de surcharges de la méthode Load qui spécifient des tableaux d'octets.
Les assemblys qui ont été compilés en code natif à l'aide de Ngen.exe (Native Image Generator) peuvent être partagés entre des domaines d'application, s'ils sont chargés comme indépendants du domaine lors de leur premier chargement dans un processus.
Le code compilé juste-à-temps pour l'assembly contenant le point d'entrée de l'application est partagé uniquement si toutes ses dépendances peuvent être partagées.
Un assembly indépendant du domaine peut être compilé juste-à-temps plusieurs fois. Par exemple, lorsque les jeux d'autorisations de sécurité de deux domaines d'application sont différents, ils ne peuvent pas partager le même code compilé juste-à-temps. Toutefois, chaque copie de l'assembly compilé juste-à-temps peut être partagée avec d'autres domaines d'application disposant du même jeu d'autorisations.
Lorsque vous décidez de charger des assemblys comme indépendants du domaine, vous devez trouver un compromis entre la réduction de l'utilisation de la mémoire et d'autres facteurs de performances.
L'accès aux données et méthodes statiques est plus lent pour les assemblys indépendants du domaine en raison de la nécessité d'assurer l'isolation des assemblys. Chaque domaine d'application qui accède à l'assembly doit disposer d'une copie distincte des données statiques, afin d'éviter que des références à des objets dans les champs statiques ne franchissent les limites de domaine. Le runtime contient par conséquent une logique supplémentaire pour orienter un appelant vers la copie appropriée des données statiques ou de la méthode statique. Cette logique supplémentaire ralentit l'appel.
Toutes les dépendances d'un assembly doivent être localisées et chargées lorsque l'assembly est chargé comme indépendant du domaine, car une dépendance qui ne peut pas être chargée comme indépendante du domaine empêche le chargement de l'assembly comme indépendant du domaine.