Je ne comprends pas les domaines d’application

.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 obtenir des connaissances supplémentaires sur ce sujet, mais cela semble très rare.

Tout ce que je sais faire avec Application Domains, c’est de charger des assemblys en mémoire et de les décharger quand je veux.

Quelles sont les autres fonctionnalités que j’ai mentionnées des domaines d’application? Les threads respectent-ils les limites des domaines d’application? Existe-t-il des inconvénients liés au chargement d’assemblages dans différents domaines d’application autres que les principaux domaines d’application au-delà des performances de communication?

Des liens vers des ressources traitant des domaines d’application seraient également intéressants. J’ai déjà vérifié MSDN qui ne contient pas beaucoup d’informations à leur sujet.

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

    Il peut y avoir N AppDomains par processus .Net mais en général, il n’y en a qu’un. Le véritable avantage d’AppDomains est qu’ils fournissent une limite d’isolement au sein de votre processus. Les objects ne peuvent se parler qu’à travers une limite AppDomain via la communication à distance 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 sur Full Trust lors de l’exécution de plug-ins non approuvés à un niveau de confiance nettement inférieur.

    Difficile de dire oui ou non à la question de savoir si un thread respecte ou non un AppDomain. Il est possible qu’un seul thread se trouve dans N AppDomains différents. Une telle situation est possible si un object dans un AppDomain effectue un appel distant à un object dans un autre AppDomain. Le thread devra effectuer une transition entre les AppDomains pour pouvoir terminer.

    L’inconvénient d’AppDomains est principalement la complexité. Remoting peut prendre un peu de temps pour bien comprendre et configurer correctement un AppDomain peut être un processus non sortingvial.

    Vous souhaiterez peut-être consulter la documentation MSDN sur AppDomains. Il est difficile de trouver un didacticiel succinct qui les décrit car ils présentent une variété de fonctionnalités complexes. Cela fournit une belle vue d’ensemble qui, si elle ne répond pas directement à votre question, vous indiquera au moins au bon endroit.

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

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

    La réponse de JaredPar est bonne, sauf qu’il ne prend pas en compte la raison d’être d’AppDomains, à savoir que vous ne pouvez DECHARGER qu’un assembly en déchargeant son AppDomain. Si vous êtes un processus OS de longue durée, et que vous vous attendez à devoir charger puis décharger des assemblys pour une raison quelconque, vous avez besoin d’un AppDomain. L’exemple prototypique ici est ASP.NET, qui charge les assemblages de code d’application à la demande et peut ensuite les décharger ultérieurement, 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 via la limite AppDomain, Ne pas pouvoir effectuer un appel de méthode simple. Vous devez gérer le cycle de vie AppDomain. Etc.

    Si vous avez juste besoin de charger dynamicment des assemblages et ne pensez pas que vous devrez les décharger pendant la durée d’un processus unique, vous n’avez probablement pas besoin d’exécuter plusieurs AppDomains. Un bon exemple pourrait être une application riche qui prend en charge un modèle de plug-in, où elle parsing les assemblages de plug-ins dans un répertoire “etc” et les charge tous. Toutefois, si le modèle de plug-in nécessite le déchargement des plug-ins … eh bien.

    Il existe des scénarios plus extrêmes. Comme, 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 d’AppDomains est le processus de longue durée devant pouvoir décharger les assemblys.

    Bien entendu, les applications peuvent s’appuyer sur le processus du système d’exploitation lorsque vous souhaitez décharger un assembly. En d’autres termes, vous pourriez avoir 3 ou 4 processus coopérants en cours d’exécution, chacun avec son propre ensemble d’assemblys, et lorsque vous souhaitez décharger un assembly, fermez simplement le processus qui héberge cet assembly. Mais AppDomain offre un mécanisme plus performant pour ce faire, sans nécessiter des communications arrêt / démarrage ou inter-processus, qui sont encore plus lourdes que les communications cross-AppDomain décrites précédemment. Je veux dire que ça remote encore, mais c’est plus lent et plus de changement de contexte.

    Certaines choses que vous pouvez faire avec AppDomains:

    • vous pouvez le fermer sans compromettre la stabilité de votre programme.
    • Vous pouvez charger du code et accorder moins de privilèges que votre propre processus (par exemple, votre processus est entièrement sécurisé, mais vous chargez du code dans un AppDomain distinct qui ne peut même pas créer de fichier sur le disque).
    • Vous pouvez gérer les exceptions non gérées d’un AppDomain sans avoir à bloquer votre processus.
    • Etc.

    En termes simples, c’est une limite de sécurité et presque une limite de processus. En ce qui concerne les performances, plusieurs AppDomains au sein d’un processus ne représentent pas une charge importante. Lancer un processus distinct au lieu d’un AppDomain est beaucoup plus coûteux.