que - ¡No hay dominios de aplicación en.NET Core! ¿Por qué?
porque usar.net core (5)
Actualización para .NET Standard 2 y .NET Core 2
En .NET Standard 2, la clase
AppDomain
está
allí.
Sin embargo, muchas partes de esa API generarán una
PlatformNotSupportedException
para .NET Core.
La razón principal por la que todavía está allí es para cosas básicas como registrar un controlador de excepciones no controlado que funcionará.
Las preguntas frecuentes de .NET Standard tienen esta explicación :
¿AppDomain forma parte de .NET Standard?
El tipo AppDomain es parte de .NET Standard. No todas las plataformas admitirán la creación de nuevos dominios de aplicaciones, por ejemplo, .NET Core no lo hará, por lo que el método AppDomain.CreateDomain mientras esté disponible en .NET Standard podría arrojar PlatformNotSupportedException.
La razón principal por la que exponemos este tipo en .NET Standard es porque el uso es bastante alto y, por lo general, no está asociado con la creación de nuevos dominios de aplicación, sino para interactuar con el dominio de la aplicación actual, como registrar un controlador de excepciones no controlado o solicitar el directorio base de la aplicación .
Además de eso, la respuesta principal y otras respuestas también explican muy bien por qué la mayor parte de AppDomain todavía se cortó (por ejemplo, arroja una excepción no compatible).
¿Existe una razón sólida por la que Microsoft decidió no admitir AppDomains en .NET Core?
Los AppDomains son particularmente útiles cuando se compilan aplicaciones de servidor de larga ejecución, donde es posible que queramos actualizar los ensamblados cargados por el servidor de una manera elegante, sin apagar el servidor.
Sin AppDomains, ¿cómo vamos a reemplazar nuestros ensamblados en un proceso de servidor de larga ejecución?
AppDomains también nos proporciona una forma de aislar diferentes partes del código del servidor. Al igual, un servidor websocket personalizado puede tener un código de socket en el dominio de aplicación principal, mientras que nuestros servicios se ejecutan en un dominio de aplicación secundario.
Sin AppDomains, el escenario anterior no es posible.
Puedo ver un argumento que puede hablar sobre el uso del concepto de VM de Cloud para manejar los cambios de ensamblado y no tener que incurrir en la sobrecarga de AppDomains. ¿Pero es esto lo que Microsoft piensa o dice? o tienen una razón específica y alternativas para los escenarios anteriores?
App Dominios
¿Por qué fue descontinuado? Los AppDomains requieren soporte de tiempo de ejecución y generalmente son bastante caros. Si bien CoreCLR todavía lo implementa, no está disponible en .NET Native y no planeamos agregar esta capacidad allí.
¿Qué debo usar en su lugar? Los AppDomains se usaron para diferentes propósitos. Para el aislamiento del código, recomendamos procesos y / o contenedores. Para la carga dinámica de ensamblajes, recomendamos la nueva clase AssemblyLoadContext.
El objetivo del subconjunto .NETCore era mantener una instalación .NET pequeña . Y fácil de transportar. Es por eso que puede, por ejemplo, ejecutar una aplicación Silverlight tanto en Windows como en OSX y no esperar mucho cuando visita la página web. Descargar e instalar el tiempo de ejecución completo y el marco lleva unos segundos, más o menos.
Mantenerlo pequeño inevitablemente requiere que se corten características. Remoting era muy alto en esa lista, es bastante costoso. De lo contrario, está bien oculto, pero puede ver, por ejemplo, que los delegados ya no tienen un método BeginInvoke () funcional. Lo que también puso AppDomain en la lista de corte, no puede ejecutar código en un dominio de aplicación sin soporte remoto. Entonces esto es completamente por diseño.
En un momento, escuché que la descarga de ensamblajes se habilitaría sin usar dominios.
Creo que el tipo
System.Runtime.Loader.AssemblyLoadContext
en System.Runtime.Loader.dll está relacionado con este trabajo, pero todavía no veo nada que permita la descarga.
He escuchado en una conversación comunitaria o alguna conversación sobre Microsoft que la característica de aislamiento de AppDomains se maneja mejor mediante procesos (y en realidad el patrón común en otras plataformas) y que la descarga está planificada como una característica normal no relacionada con AppDomains.