No entiendo Dominios de aplicación

Question

.NET tiene este concepto de dominios de aplicación que, según tengo entendido, se puede usar para cargar un ensamblaje en la memoria. Investigué un poco sobre los dominios de aplicación y también fui a mi librería local para obtener más información sobre este tema, pero parece muy escasa.

Todo lo que sé que puedo hacer con Application Domains es cargar ensamblajes en la memoria y puedo descargarlos cuando quiera.

¿Cuáles son las capacidades que he mencionado de los dominios de aplicación? ¿Los hilos respetan los límites de los dominios de aplicación? ¿Hay algún inconveniente al cargar ensamblajes en diferentes dominios de aplicaciones distintos de los principales dominios de aplicación más allá del rendimiento de la comunicación?

Los enlaces a los recursos que discuten los dominios de aplicación también serían agradables. Ya revisé MSDN, que no tiene mucha información sobre ellos.

Answer 1

AppDomains se visualiza mejor como un proceso muy liviano.

Puede haber N AppDomains por .Net Process pero en general solo hay uno. La ventaja real de AppDomains es que proporcionan un límite de aislamiento dentro de su proceso. Los objetos solo pueden comunicarse entre sí a través de un límite de AppDomain mediante comunicación remota o serialización.

También es posible ejecutar 2 AppDomains en niveles de seguridad completamente diferentes dentro de un proceso. Esto puede permitirle ejecutar su aplicación principal en Full Trust mientras ejecuta los complementos que no son de confianza a un nivel de confianza mucho más bajo.

Es difícil describir si sí o no si un hilo respeta o no un Dominio de aplicación. Es posible que un único hilo esté en N diferentes AppDomains. Tal situación es posible si un objeto en un AppDomain hace una llamada remota a un objeto en otro AppDomain. El hilo tendrá que hacer una transición entre los AppDomains para completar.

La desventaja de AppDomains es principalmente la complejidad. Remoting puede tomar un poco de tiempo para darse cuenta y configurar correctamente un AppDomain puede ser un proceso no trivial.

Es posible que desee echar un vistazo a través de la documentación de MSDN en AppDomains. Es difícil encontrar un tutorial sucinto que los describa porque tienen una variedad de características complejas. Esto proporciona una buena visión general que, si no responde a su pregunta directamente, al menos lo indicará en el lugar correcto.

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

Este documento ya no se mantiene por favor refiérase a esto para la versión actualizada: https://msdn.microsoft.com/en-us/library/2bh4z9hs(v=vs.110).aspx

Answer 2

Algunas cosas que puede hacer con dominios de aplicación:

• que es posible apagarlo sin poniendo en peligro la estabilidad de su programa.
• Puede cargar Código de manera que esto sea menos privilegios entonces su propio proceso (por ejemplo, el proceso se ejecuta de plena confianza, pero se carga código en un dominio de aplicación independiente que ni siquiera se puede crear un archivo en el disco.)
• Puede gestionar las excepciones no controladas de un AppDomain sin tener que bloquear su proceso.
• Etc.

En pocas palabras, es un límite de seguridad y casi un límite de proceso. En lo que respecta al rendimiento, múltiples AppDomains dentro de un proceso no representan una sobrecarga significativa. Lanzar un proceso separado en lugar de un AppDomain es mucho más costoso.

Answer 3

La respuesta de JaredPar es buena, excepto que él no nota el raison d'etre para AppDomains, que es que solo puede DESCARGAR un Ensamblaje descargando su AppDomain. Si usted es un proceso de sistema operativo de larga ejecución y espera tener que cargar y luego descargar ensamblajes por cualquier razón, entonces necesita un Dominio de aplicación. El ejemplo prototípico aquí es ASP.NET, que carga ensamblajes de código de aplicación bajo demanda y luego puede descargarlos más tarde, cuando las aplicaciones ya no se usan activamente.

El costo que paga por la capacidad de descarga es esa independencia; necesita comunicarse a través del límite del Dominio de la aplicación. No se puede hacer una llamada a un método simple. Debe administrar el ciclo de vida de AppDomain. Etc.

Si sólo tiene que cargar dinámicamente las asambleas y no creo que se necesita para descargarlos durante la vida de un solo proceso entonces es probable que no necesita ejecutar múltiples dominios de aplicación. Un buen ejemplo aquí podría ser una aplicación enriquecida que admita un modelo de complemento, en el que detecte los ensamblados de los complementos en un directorio "etc." y los cargue todo. Sin embargo, si el modelo de complemento solicita la descarga de los complementos ... bueno.

Hay escenarios externos. Como, supongamos que desea cargar 2 versiones diferentes de un ensamblaje al mismo tiempo. Puede encontrarse con dificultades si no las segrega con AppDomains. Pero eso será bastante raro.

El escenario principal que justifica la existencia de AppDomains es el proceso de larga ejecución que debe poder descargar ensamblados.

Por supuesto, las aplicaciones pueden confiar en el proceso de SO cuando desee descargar un ensamblaje. En otras palabras, podría tener 3 o 4 procesos en cooperación en ejecución, cada uno con su propio conjunto de ensamblajes, y cuando desee descargar un ensamblaje, simplemente cierre el proceso que aloja ese ensamblado. Sin embargo, AppDomain ofrece un mecanismo de mayor rendimiento para hacer eso, sin requerir procesos stop/start o cross-process comms, que es más pesado que las comunicaciones entre dominios AppDomain descritas anteriormente. Quiero decir que todavía es remota pero es más lenta y con más cambio de contexto.