Détermination des limites de domaine d'application
Une fois que le code d'hébergement a effectué la transition du code non managé au code managé, il doit créer un ou plusieurs nouveaux domaines d'application dans lesquels exécuter le code utilisateur. Un domaine d'application est une construction que les hôtes utilisent pour isoler le code s'exécutant dans un processus. Cette isolation est nécessaire pour que le code qui n'est pas destiné à entrer en interaction n'interagisse pas. Par exemple, les codes téléchargés à partir de deux sites Web différents vers l'hôte Internet Explorer doivent être maintenus séparés. L'hôte Internet Explorer crée un domaine d'application pour chaque site pour assurer cette isolation.
Avant qu'un hôte ne puisse créer un domaine d'application dans lequel exécuter le code utilisateur, il doit déterminer l'emplacement des limites du nouveau domaine d'application. Les facteurs qui motivent cette décision prennent en compte les exigences de restriction de l'accès d'un type particulier à d'autres types, la configuration, la sécurité et la capacité à décharger le code lorsqu'il n'est plus nécessaire.
Restriction de l'accès à des types
Un type s'exécutant dans un domaine d'application peut découvrir d'autres types s'exécutant dans le domaine et les appeler directement. Un type ne peut toutefois jamais découvrir des types s'exécutant dans d'autres domaines d'application ni les appeler. La capacité à restreindre l'accès d'un type à d'autres types est un point essentiel dans la détermination de l'emplacement dans lequel créer les limites de domaine.
Paramètres de configuration
Les domaines d'application sont les unités de configuration principales du runtime. Chaque domaine d'application possède un fichier de configuration associé optionnel qui décrit les paramètres relatifs au code s'exécutant dans le domaine.
Par exemple, un fichier de configuration peut contenir une liste de répertoires dans lesquels se trouvent les assemblys privés, des informations sur les liaisons de version pour les assemblys partagés, l'emplacement des types pouvant être accédés à distance, etc.
Sécurité
Les hôtes peuvent définir à la fois une stratégie de sécurité d'accès du code et une stratégie de sécurité basée sur les rôles pour un domaine. Cela permet à l'hôte de contrôler l'ensemble des autorisations accordées au code dans un domaine particulier et de définir à la fois l'entité du thread en cours et l'entité par défaut de la sécurité basée sur les rôles.
Par exemple, un hôte peut définir une stratégie de sécurité d'accès du code au niveau du domaine d'application, de telle sorte que seul le code téléchargé à partir d'un site particulier puisse être exécuté dans le domaine. Un hôte peut également définir les entités de sécurité basée sur les rôles pour implémenter un schéma d'authentification personnalisé.
Déchargement du code
Pour décharger le code managé s'exécutant dans un processus à partir de la mémoire pour que la mémoire puisse être utilisée à d'autres fins, l'hôte doit décharger le domaine d'application dans lequel le code s'exécute. Des assemblys ou des types individuels ne peuvent pas être déchargés. L'hôte possède ses propres règles qui régissent le moment où vous pouvez décharger le code utilisateur. Par exemple, votre navigateur Internet peut charger des contrôles managés dans le domaine déterminé d'un site. Le navigateur peut ensuite disposer de règles qui lui permettent de conserver les pages les plus récemment consultées dans la mémoire pour que les boutons Précédente et Suivante répondent plus rapidement. Lorsque le navigateur détermine qu'une page n'est plus nécessaire dans la mémoire, il supprime le domaine d'application et supprime de ce fait également le code des contrôles managés.