.net - para - dominio de aplicacion

No entiendo los dominios de aplicaciones

Question

.NET tiene este concepto de dominios de aplicación que, por lo que entiendo, 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 Application Domains? ¿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

Algunas cosas que puedes hacer con AppDomains:

• puede cerrarlo sin poner en peligro la estabilidad de su programa.
• Puede cargar código y otorgarle menos privilegios que su propio proceso (p. Ej., Su proceso es totalmente confiable pero carga el código en un Dominio de aplicación diferente que ni siquiera puede crear un archivo en el disco).
• Puede manejar 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 2

AppDomains se visualiza mejor como un proceso muy ligero.

Puede haber N AppDomains por proceso .Net, 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 decir 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 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; consulte la versión actualizada en esta página: https://msdn.microsoft.com/en-us/library/2bh4z9hs(v=vs.110).aspx

Answer 3

La respuesta de JaredPar es buena, excepto que no tiene en cuenta la razón de ser de AppDomains, que es que solo puedes 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 puede hacer una llamada a un método simple. Debe administrar el ciclo de vida de AppDomain. Etc.

Si solo necesita cargar dinámicamente Asambleas y no cree que deba descargarlas durante la vida de un solo proceso, entonces probablemente no necesite ejecutar múltiples AppDomains. 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 del 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.