Vue d'ensemble des domaines d'application
Mise à jour : novembre 2007
Du point de vue historique, les limites de processus ont permis d'isoler les applications en cours d'exécution sur le même ordinateur. Chaque application est chargée dans un processus distinct, ce qui isole l'application des autres applications en cours d'exécution sur le même ordinateur.
Les applications sont isolées, car les adresses mémoire sont liées au processus ; un pointeur mémoire passé d'un processus à un autre ne peut pas être utilisé d'une manière significative dans le processus cible. De plus, vous ne pouvez pas établir d'appels directs entre deux processus. Vous devez à la place utiliser des proxies qui génèrent un niveau d'adressage indirect.
Le code managé doit passer par un processus de vérification avant de pouvoir être exécuté (sauf si l'administrateur a accordé l'autorisation d'ignorer la vérification). Le processus de vérification détermine si le code peut essayer d'accéder à des adresses mémoire non valides ou effectuer d'autres actions risquant d'empêcher le processus dans lequel il s'exécute de fonctionner correctement. Le code qui réussit le test de vérification est considéré comme étant de type sécurisé. La capacité à vérifier si le code est de type sécurisé permet au Common Language Runtime d'assurer un niveau d'isolation aussi élevé que celui de la limite de processus, à un coût de performances beaucoup plus réduit.
Les domaines d'application fournissent une unité de traitement davantage sécurisée et polyvalente que le Common Language Runtime peut utiliser pour assurer l'isolation entre les applications. Vous pouvez exécuter plusieurs domaines d'application dans un seul processus avec le même niveau d'isolation que dans des processus distincts, mais sans risquer une surcharge mémoire en établissant des appels interprocessus ou en passant d'un processus à un autre. La capacité à exécuter plusieurs applications dans un seul processus optimise considérablement l'évolutivité du serveur.
L'isolation des applications est également importante pour la sécurité des applications. Par exemple, vous pouvez exécuter des contrôles à partir de plusieurs applications Web dans un seul processus de navigateur, de telle sorte que les contrôles ne puissent pas accéder à leurs données et à leurs ressources respectives.
L'isolation assurée par les domaines d'application présente les avantages suivants :
Les erreurs survenues dans une application ne peuvent pas affecter d'autres applications. Comme le code de type sécurisé ne risque pas de provoquer d'erreurs dans la mémoire, l'utilisation de domaines d'application permet d'empêcher le code en cours d'exécution dans un domaine d'affecter d'autres applications dans le processus.
Des applications individuelles peuvent être arrêtées sans que le processus entier soit arrêté. L'utilisation des domaines d'application vous permet de décharger le code en cours d'exécution dans une seule application.
.gif "Remarque")
Remarque :Vous ne pouvez pas décharger des assemblys ou des types individuels. Seul un domaine complet peut être déchargé.
Le code en cours d'exécution dans une application ne peut pas directement accéder au code ou aux ressources d'une autre application. Le Common Language Runtime applique cette isolation en empêchant les appels directs entre les objets dans les différents domaines d'application. Les objets qui passent d'un domaine à un autre sont soit copiés, soit accédés par un proxy. Si l'objet est copié, l'appel à cet objet est alors local. Dans ce cas, l'appelant et l'objet référencé figurent dans le même domaine d'application. Si l'objet est accédé par un proxy, l'appel à cet objet est alors distant. Dans ce cas, l'appelant et l'objet référencé figurent dans des domaines d'application différents. Les appels interdomaines utilisent la même infrastructure d'appel distant que les appels entre deux processus ou deux ordinateurs. Les métadonnées de l'objet référencé doivent par conséquent être disponibles pour les deux domaines d'application pour que l'appel de méthode puisse faire l'objet d'une compilation JIT correcte. Si le domaine appelant n'a pas accès aux métadonnées pour l'objet qui est appelé, la compilation peut échouer avec une exception de type System.IO.FileNotFound. Pour plus d'informations, consultez .Accès distant .NET. Le mécanisme permettant de déterminer le mode d'accès des objets sur les domaines est défini par l'objet. Pour plus d'informations, consultez MarshalByRefObject, classe.
La portée du comportement de code est définie par l'application dans laquelle il s'exécute. En d'autres termes, le domaine d'application fournit des paramètres de configuration tels que les stratégies de version d'application, l'emplacement des assemblys distants auxquels il accède et des informations sur l'emplacement où se trouvent les assemblys qui sont chargés dans le domaine.
Les autorisations accordées au code peuvent être contrôlées par le domaine d'application dans lequel le code s'exécute.