Je ne comprends pas Domaines d'application

Question

.NET a ce concept de domaines d'application qui, d'après ce que je comprends, peut être utilisé pour charger un assemblage en mémoire. J'ai fait des recherches sur les domaines d'application et je me suis rendu dans ma librairie locale pour avoir des connaissances supplémentaires sur ce sujet, mais cela semble très rare. Tout ce que je peux faire avec les Domaines d'Application, c'est de charger des assemblages en mémoire et de les décharger quand je le veux.

Quelles sont les fonctionnalités que j'ai mentionnées des domaines d'application? Les threads respectent-ils les limites des domaines d'application? Y a-t-il des inconvénients à charger des assemblages dans différents domaines d'application autres que les domaines d'application principaux au-delà de la performance de communication?

Les liens vers des ressources qui traitent des domaines d'application seraient également intéressants. J'ai déjà vérifié MSDN qui n'a pas beaucoup d'informations à leur sujet.

Answer 1

AppDomaines mieux visualisés comme un processus très léger.

Il peut y avoir N AppDomains par .Net Process mais en général il n'y en a qu'un seul. Le véritable avantage de AppDomains est qu'ils fournissent une limite d'isolement au sein de votre processus. Les objets ne peuvent communiquer entre eux qu'à travers une frontière AppDomain via l'accès distant ou la sérialisation.

Il est également possible d'exécuter 2 AppDomains à des niveaux de sécurité complètement différents au sein d'un processus. Cela peut vous permettre d'exécuter votre application principale à pleine confiance tout en exécutant des plugins non approuvés à un niveau de confiance beaucoup plus faible.

Il est difficile de dire oui ou non si un thread respecte un AppDomain. Il est possible qu'un seul thread soit dans N différents AppDomains. Une telle situation est possible si un objet dans un AppDomain effectue un appel distant à un objet dans un autre AppDomain. Le thread devra effectuer une transition entre les AppDomains pour terminer.

L'inconvénient de AppDomains est principalement la complexité. Remoting peut prendre un peu de temps pour vous mettre en forme et configurer correctement un AppDomain peut être un processus non trivial.

Vous souhaiterez peut-être jeter un coup d'œil à la documentation MSDN sur AppDomains. Il est difficile de trouver un tutoriel succint qui les décrit parce qu'ils ont une variété de fonctionnalités complexes. Cela donne un bon aperçu qui, s'il ne répond pas directement à votre question, vous indiquera au moins le bon endroit.

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

Ce document n'est plus maintenu s'il vous plaît se référer à cela pour la version mise à jour: https://msdn.microsoft.com/en-us/library/2bh4z9hs(v=vs.110).aspx

Answer 2

Certaines choses que vous pouvez faire avec AppDomains:

• vous pouvez l'éteindre sans mettre en péril la stabilité de votre programme.
• Vous pouvez charger du code et lui donner moins de privilèges que votre propre processus (par exemple, votre processus est entièrement fiable mais vous chargez du code dans un AppDomain distinct qui ne peut même pas créer un fichier sur le disque). d'un AppDomain sans avoir à planter votre processus.
• Etc.

En termes simples, il s'agit d'une frontière de sécurité et d'une frontière de processus. En ce qui concerne les performances, plusieurs AppDomains au sein d'un processus ne représentent pas un surcoût significatif. Lancer un processus séparé au lieu d'un AppDomain est beaucoup plus coûteux.

Answer 3

La réponse de JaredPar est bonne, sauf qu'il ne note pas le raison d'etre pour AppDomains - qui est que vous ne pouvez DÉCHARGER un assemblage qu'en déchargeant son AppDomain. Si vous êtes un processus de système d'exploitation de longue durée, et que vous vous attendez à devoir charger puis décharger des assemblages pour une raison quelconque, vous avez besoin d'un AppDomain. L'exemple prototype ici est ASP.NET, qui charge les assemblys de code d'application à la demande et peut ensuite les décharger plus tard, lorsque les applications ne sont plus utilisées activement.

Le coût que vous payez pour la capacité de déchargement est cette indépendance - vous devez communiquer à travers la limite AppDomain, Impossible de faire un appel de méthode simple. Vous devez gérer le cycle de vie AppDomain. Etc.

Si vous avez juste besoin de charger les assemblées et ne pensez pas de façon dynamique, vous aurez besoin de les décharger au cours de la vie d'un seul processus alors vous avez probablement ne besoin d'exécuter plusieurs domaines d'application. Un bon exemple ici pourrait être une application riche qui prend en charge un modèle de plug-in, où il renifle les assemblys de plug-ins dans un répertoire "etc" et les charge tous. Cependant, si le modèle de plug-in appelle le déchargement des plug-ins ... eh bien.

Il existe des scénarios plus éloignés. Supposons que vous vouliez charger deux versions différentes d'un assemblage en même temps. Vous pouvez rencontrer des pièges si vous ne les séparez pas avec AppDomains. Mais ce sera assez rare.

Le scénario de base qui justifie l'existence de AppDomains est le processus de longue durée qui doit pouvoir décharger des assemblys.

Bien sûr, les applications peuvent s'appuyer sur le processus du système d'exploitation lorsque vous voulez décharger un assemblage. En d'autres termes, vous pouvez exécuter 3 ou 4 processus de coopération, chacun avec son propre ensemble d'assemblys, et lorsque vous voulez décharger un assembly, arrêtez simplement le processus qui héberge cet assembly. Toutefois, l'AppDomain offre un mécanisme de meilleure performance pour ce faire, sans nécessiter de processus stop/start ou inter-process, ce qui est plus lourd que les communications inter-AppDomain décrites précédemment. Je veux dire c'est encore à distance mais c'est plus lent et plus de changement de contexte.