c# .net appdomain

c# - ¿Qué es AppDomain?



.net (3)

Esta pregunta ya tiene una respuesta aquí:

¿Qué es un AppDomain ? ¿Cuáles son los beneficios de AppDomains o por qué Microsoft trajo el concepto de AppDomains, cuál fue el problema sin AppDomains?

Por favor elabora.


AppDomains se puede ver como procesos livianos. Comparten muchas de las mismas características de un proceso, por ejemplo, tienen sus propias copias de estática, ensamblajes, etc., pero están contenidos en un solo proceso. Desde el punto de vista del sistema operativo, un proceso es solo un proceso, no importa cuántos AppDomains pueda contener.

Sin embargo, a diferencia de un proceso, un AppDomain no tiene subprocesos a menos que los cree explícitamente. Un hilo puede ejecutar código en cualquier dominio de aplicación.

Los AppDomains son parte del mismo proceso y, por lo tanto, comparten el mismo montón gestionado. Esto generalmente no es un problema ya que el modelo de programación AppDomain evita el acceso implícito entre los AppDomains. Sin embargo, algunas referencias se comparten realmente entre los AppDomains, como los objetos tipo y las cadenas internas.


Un dominio de aplicación implementa el concepto de un espacio contiguo de memoria virtual que contiene el código y los recursos en memoria a los que se puede acceder o hacer referencia directamente.

Los AppDomains separados no comparten espacio de memoria y, en consecuencia, un AppDomain no puede hacer referencia directamente a los contenidos en otro. En particular, los datos deben pasarse entre AppDomains a través de un proceso de copia por valor. En particular, los objetos de referencia, que dependen de los punteros y, por lo tanto, de las direcciones de memoria, primero deben serializarse desde la fuente y luego deserializarse en el AppDomain de destino.

Anteriormente en los sistemas Windows, los límites de memoria se implementaban mediante procesos; sin embargo, construir procesos requiere muchos recursos. También sirven un doble propósito como límites de hilo. Los dominios de aplicación, por otro lado, se refieren solo al límite de memoria o espacio de direcciones. Los subprocesos pueden "fluir" a través de AppDomains (es decir, un procedimiento puede invocar un punto de entrada en otro AppDomain y esperar a que vuelva. Se dice que el subproceso ''continúa'' la ejecución dentro del otro Dominio de aplicación).

Un beneficio significativo de esta arquitectura es que los patrones de comunicación entre los dominios de aplicaciones permanecen sustancialmente sin cambios tanto si los AppDomains están en el mismo proceso, diferentes procesos o en diferentes máquinas juntas: el proceso de serialización y deserialización (recopilación) de datos de parámetros .

Nota 1: el significado de un hilo que cruza un AppDomain es el de un método de bloqueo o sincrónico en otro AppDomain (frente a una llamada no bloqueante o asincrónica que engendraría otro hilo para continuar la ejecución en el AppDomain objetivo y continuar en su AppDomain actual) sin esperar respuesta).

Nota 2: existe algo como Thread Local Storage. Sin embargo, un nombre mejor habría sido el almacenamiento local de subprocesos en el dominio de la aplicación, ya que los subprocesos dejan sus datos atrás cuando cruzan los dominios de la aplicación, pero los recuperan una vez que regresan: http://msdn.microsoft.com/en-us/library/6sby1byh.aspx

Nota 3: A .Net Runtime es una aplicación de proceso de Windows con un montón asociado. Puede albergar uno o más AppDomains en ese montón. Sin embargo, los AppDomains están diseñados para no tener en cuenta el uno al otro y para comunicarse entre ellos a través del cálculo de referencias. Es concebible que se pueda realizar una optimización que evite el cálculo de referencias entre AppDomains comunicantes que comparten el mismo .Net Runtime y, por lo tanto, el mismo montón de Windows Process.


Un AppDomain proporciona una capa de aislamiento dentro de un proceso. Todo lo que usualmente se considera como "por programa" (variables estáticas, etc.) es en realidad por cada dominio de aplicación. Esto es útil para:

  • complementos (puede descargar un AppDomain , pero no un ensamblado dentro de un AppDomain )
  • seguridad (puede ejecutar un conjunto de códigos con niveles de confianza específicos)
  • aislamiento (puede ejecutar diferentes versiones de ensambles, etc.)

El dolor es que necesitas usar la comunicación remota, etc.

Vea MSDN para mucha más información. Para ser honesto, no es algo con lo que deba meterse con frecuencia.