Aucun AppDomains dans .NET Core! Pourquoi?

Existe-t-il une forte raison pour laquelle Microsoft a choisi de ne pas prendre en charge AppDomains dans .NET Core?

Les AppDomains sont particulièrement utiles lors de la création d’applications serveur longues, sur lesquelles nous souhaitons peut-être mettre à jour les assemblys chargés par le serveur, sans arrêter le serveur.

Sans AppDomains, comment allons-nous remplacer nos assemblys dans un long processus serveur?

AppDomains nous fournit également un moyen d’isoler différentes parties du code du serveur. Comme, un serveur websocket personnalisé peut avoir un code de socket dans un domaine principal, tandis que nos services s’exécutent dans un domaine secondaire.

Sans AppDomains, le scénario ci-dessus n’est pas possible.

Je peux voir un argument qui pourrait parler de l’utilisation du concept de VM de Cloud pour gérer les modifications d’assemblage et ne pas avoir à supporter la surcharge d’AppDomains. Mais est-ce ce que Microsoft pense ou dit? ou ont-ils une raison spécifique et des alternatives pour les scénarios ci-dessus?

Le point du sous-ensemble .NETCore était de garder une petite installation .NET. Et facile à mettre en communication. C’est pourquoi vous pouvez, par exemple, exécuter une application Silverlight sur Windows et OSX et ne pas attendre très longtemps lorsque vous visitez la page Web. Le téléchargement et l’installation du runtime et du framework complets ne prennent que quelques secondes.

Le garder petit nécessite inévitablement des fonctionnalités à couper. La communication à distance était très élevée sur cette liste, c’est assez cher. Sinon, bien caché, mais vous pouvez par exemple voir que les delegates n’ont plus de méthode fonctionnelle BeginInvoke (). Qui placent également AppDomain sur la liste de coupe, vous ne pouvez pas exécuter de code dans un domaine d’application sans assistance à distance. Donc, c’est entièrement par conception.

Mise à jour pour .NET Standard 2 et .NET Core 2

Dans .NET Standard 2, la classe AppDomain est présente. Cependant, de nombreuses parties de cette API lanceront une PlatformNotSupportedException pour .NET Core.

La principale raison pour laquelle il est toujours là est pour des choses basiques comme l’enregistrement d’un gestionnaire d’exceptions non géré qui fonctionnera.

La norme .NET Standard a cette explication :

AppDomain fait-il partie de .NET Standard?

Le type AppDomain fait partie de .NET Standard. Toutes les plates-formes ne prendront pas en charge la création de nouveaux domaines d’application, par exemple, .NET Core ne le sera pas. Par conséquent, la méthode AppDomain.CreateDomain étant disponible dans .NET Standard pourrait lancer PlatformNotSupportedException.

La principale raison pour laquelle nous exposons ce type dans .NET Standard est que son utilisation est relativement élevée et généralement pas associée à la création de nouveaux domaines d’application, mais à un gestionnaire d’exceptions non géré ou au répertoire de base de l’application. .

En dehors de cela, la meilleure réponse et les autres réponses expliquent bien pourquoi la majeure partie d’AppDomain était encore coupée (par exemple, lève une exception non prise en charge).

À un moment donné, j’ai entendu que les assemblages de déchargement seraient activés sans utiliser de domaines. Je pense que le type System.Runtime.Loader.AssemblyLoadContext dans System.Runtime.Loader.dll est lié à ce travail, mais je ne vois rien là-bas qui permet encore le déchargement.

J’ai entendu dans un stand de communauté ou à propos de Microsoft que la fonction d’isolation d’AppDomains est mieux gérée par les processus (et en fait le modèle commun sur d’autres plates-formes) et que le déchargement est en effet planifié sans rapport avec AppDomains.

Domaines d’application

Pourquoi a-t-il été interrompu? Les AppDomains requièrent un support d’exécution et sont généralement assez coûteux. Bien que toujours implémenté par CoreCLR, il n’est pas disponible dans .NET Native et nous ne prévoyons pas d’y append cette fonctionnalité.

Que dois-je utiliser à la place? Les AppDomains ont été utilisés à des fins différentes. Pour l’isolation du code, nous recommandons les processus et / ou les conteneurs. Pour le chargement dynamic des assemblys, nous recommandons la nouvelle classe AssemblyLoadContext.

Source à partir du blog MSDN