No entiendo los dominios de la aplicación

.NET tiene este concepto de dominios de aplicación que, según tengo entendido, se puede usar para cargar un ensamblado en la memoria. He investigado un poco sobre los dominios de aplicación y he ido a mi librería local para obtener conocimientos adicionales sobre este tema, pero parece muy escaso.

Todo lo que sé que puedo hacer con los dominios de aplicación es cargar ensamblados en la memoria y puedo descargarlos cuando quiera.

¿Cuáles son las otras capacidades que he mencionado de los dominios de aplicación? ¿Los subprocesos respetan los límites de los dominios de aplicación? ¿Existe algún inconveniente al cargar ensamblados en diferentes dominios de aplicación que no sean los principales dominios de aplicación más allá del rendimiento de la comunicación?

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

AppDomains se visualiza mejor como un proceso muy ligero.

Puede haber N AppDomains por proceso .Net pero, en términos generales, solo hay uno. La ventaja real de AppDomains es que brindan 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 con niveles de seguridad completamente diferentes dentro de un proceso. Esto puede permitirle ejecutar su aplicación principal en Full Trust mientras ejecuta complementos no confiables a un nivel de confianza mucho más bajo.

Es difícil decir sí o no de manera general a si un hilo respeta o no un AppDomain. Es posible que un solo hilo esté en N AppDomains diferentes. Tal situación es posible si un objeto en un AppDomain realiza una llamada remota a un objeto en otro AppDomain. El hilo tendrá que hacer una transición entre los AppDomains para completarse.

La desventaja de AppDomains es principalmente la complejidad. La comunicación remota puede llevar un poco de tiempo para entender y configurar correctamente un AppDomain puede ser un proceso no trivial.

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

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

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

La respuesta de JaredPar es buena, excepto que no tiene en cuenta la razón de ser de AppDomains, que es que solo puede DESCARGAR un ensamblado descargando su AppDomain. Si tiene un proceso de sistema operativo de larga duración y espera tener que cargar y luego descargar ensamblados por cualquier motivo, entonces necesita un AppDomain. El ejemplo prototípico aquí es ASP.NET, que carga ensamblajes de código de aplicación a pedido y luego puede descargarlos más tarde, cuando las aplicaciones ya no se utilizan activamente.

El costo que paga por la capacidad de descargar es esa independencia: necesita comunicarse a través del límite de AppDomain. No se puede realizar una simple llamada a un método. Necesita administrar el ciclo de vida de AppDomain. Etc.

Si solo necesita cargar ensamblados dinámicamente y no cree que deba descargarlos 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, donde rastrea los ensamblajes de complementos en un directorio "etc" y los carga todos. Sin embargo, si el modelo de complementos requiere descargar los complementos ... bueno.

Hay escenarios atípicos. Supongamos que desea cargar 2 versiones diferentes de un ensamblado al mismo tiempo. Puede encontrarse con dificultades si no los separa con AppDomains. Pero eso será bastante raro.

El escenario central 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 sistema operativo cuando desee descargar un ensamblaje. En otras palabras, podría tener 3 o 4 procesos cooperativos en ejecución, cada uno con su propio conjunto de ensamblados, y cuando desee descargar un ensamblado, simplemente cierre el proceso que aloja ese ensamblado. Pero AppDomain ofrece un mecanismo de mayor rendimiento para hacer eso, sin requerir la detención / inicio del proceso o las comunicaciones entre procesos, que es aún más pesado que las comunicaciones entre AppDomain descritas anteriormente. Quiero decir, todavía es remoto, pero es más lento y cambia de contexto.

Algunas cosas que puede hacer con AppDomains:

• puede apagarlo sin poner en peligro la estabilidad de su programa.
• Puede cargar código y otorgarle menos privilegios que su propio proceso (por ejemplo, su proceso se ejecuta de manera totalmente confiable pero carga el código en un AppDomain separado 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, varios AppDomains dentro de un proceso no representan una sobrecarga significativa. Lanzar un proceso separado en lugar de un AppDomain es mucho más costoso.