Je ne comprends pas les domaines d'application

Question

.NET a ce concept de Domaines d'Application qui, à partir de ce que je comprends peut être utilisé pour charger un assembly dans la mémoire. J'ai fait quelques recherches sur les Domaines d'Application ainsi que d'aller à mon local magasin de livre pour quelques connaissances supplémentaires sur ce sujet, mais il semble très rare.

Tout ce que je sais que je peux faire avec les Domaines d'Application est à la charge des assemblages en mémoire et je peux les décharger quand je veux.

Quelles sont les capacités d'autres que j'ai mentionné des Domaines d'Application? Ne Threads respect Domaines d'Application les frontières? Existe-il des inconvénients de chargement des Assemblages dans les différents Domaines d'Application autres que les principaux Domaines d'Application au-delà de la performance de la communication?

Des liens vers des ressources qui traitent de Domaines d'Application serait bien ainsi. J'ai déjà vérifié MSDN qui n'a pas beaucoup d'informations à leur sujet.

Answer 1

Domaines d'application vu comme un très léger poids.

Il peut être N domaines d'application par .Net, mais en général il n'y en a qu'une. L'avantage réel de domaines d'application, c'est qu'ils fournissent une limite d'isolement au sein de votre processus. Les objets ne peuvent parler les uns aux autres à travers un domaine d'application limites via l'accès distant ou de sérialisation.

Il est également possible de lancer 2 domaines d'application tout à fait différents niveaux de sécurité au sein d'un processus. Cela peut vous permettre d'exécuter votre application principale à Pleine Confiance lors de l'exécution non fiables Plugins à une beaucoup plus faible niveau de confiance.

C'est dur de couverture de dire oui ou non à savoir si ou non un thread respecte un domaine d'application. Il est possible pour un seul thread à être en N de différents domaines d'application. Une telle situation est possible que si un objet dans un domaine d'application fait appel à distance à un objet dans un autre domaine d'application. Le thread aura de transition entre les domaines d'application afin de compléter.

L'inconvénient de domaines d'application est principalement de la complexité. L'accès distant peut prendre un peu de temps pour obtenir autour de votre tête et de la mise en place correctement un domaine d'application peut être un processus non négligeable.

Vous pouvez prendre un coup d'oeil à travers la documentation MSDN sur les domaines d'application. Il est difficile de trouver un sucint tutoriel qui explique parce qu'ils ont une variété de fonctions complexes. Cela donne une belle vue d'ensemble, qui, si elle ne répond pas directement à votre question permettra au moins de vous diriger dans la bonne place.

http://msdn.microsoft.com/en-us/library/cxk374d9.aspx

Answer 2

JaredPar la réponse est bonne, sauf qu'il n'a pas de noter la raison d'être pour les domaines d'application - qui est ce que vous pouvez DÉCHARGER d'une Assemblée par le déchargement de son domaine d'application. Si vous êtes un long processus du système d'exploitation, et vous vous attendez à avoir à charger , puis plus tard, déchargement des assemblages pour quelque raison que ce soit vous avez besoin d'un domaine d'application. L'exemple prototypique est ici ASP.NET qui charge le code de l'application assemblées à la demande et ensuite peut se décharger plus tard, lorsque les applications ne sont plus utilisés activement.

Le coût que vous payez pour la capacité à décharger, c'est que l'indépendance - vous besoin de communiquer à travers le domaine d'application de limite, ne Peuvent pas faire un simple appel de méthode. Vous devez gérer le domaine d'application du cycle de vie. Etc.

Si vous avez besoin de charger dynamiquement des Assemblées et ne pensez pas que vous aurez besoin de les décharger au cours de la durée de vie d'un processus unique, alors vous avez probablement n'avez pas besoin d'exécuter de multiples domaines d'application. Un bon exemple pourrait être riche d'une application qui prend en charge un modèle de plug-in, où il renifle hors plug-in assemblées dans un "etc" directory et les charges 'em all. Toutefois, si le plug-in appels de modèle pour le déchargement, les plugins ... bien.

Il y a outlyer scénarios. Comme, supposons que vous voulez charger les 2 versions différentes d'une Assemblée en même temps. Vous pouvez exécuter dans les pièges, si vous n'avez pas les séparer avec les domaines d'application. Mais qui sera assez rare.

Le scénario de base qui justifie l'existence de domaines d'application, c'est le long processus en cours d'exécution qui doit être en mesure de décharger les assemblées.

Bien sûr, les applications pourraient s'appuyer sur les processus du système d'exploitation lorsque vous souhaitez vous décharger d'une assemblée. En d'autres termes, vous pouvez avoir 3 ou 4 en coopérant processus en cours d'exécution, chacun avec son propre ensemble d'ensembles, et quand vous voulez vous décharger d'une assemblée, vient de fermer le processus qui héberge cette assemblée. Mais le domaine d'application offre une plus grande perf mécanisme pour le faire, sans nécessiter le processus de démarrage et d'arrêt ou de la croix-processus de comms, qui est plus lourd encore que la croix-domaine d'application comms décrit précédemment. Je veux dire, c'est encore l'accès distant mais il est plus lent et plus le changement de contexte.

Answer 3

Certaines choses que vous pouvez faire avec les domaines d'application:

• vous pouvez arrêter sans mettre en danger la stabilité de votre programme.
• Vous pouvez charger le code et donner moins de privilèges alors votre propre processus (par exemple, votre processus s'exécute entièrement confiance, mais vous charger le code dans un autre domaine d'application qui ne peut même créer un fichier sur le disque.)
• Vous pouvez gérer les exceptions non gérées d'un domaine d'application, sans avoir à le plantage de votre processus.
• Etc.

C'est tout simplement une limite de sécurité et allmost un processus de démarcation. Aussi loin que l'interprétation va, plusieurs domaines d'application au sein d'un processus ne représente pas une surcharge importante. Le lancement d'un processus distinct au lieu d'un domaine d'application est beaucoup plus coûteuse.