En particular, ¿cuáles son las implicaciones de ejecutar código en dos dominios de aplicación diferentes?
¿Cómo se transmiten normalmente los datos a través del límite del dominio de la aplicación? ¿Es lo mismo que pasar datos a través de los límites del proceso? Tengo curiosidad por saber más sobre esta abstracción y para qué es útil.
EDITAR: Buena cobertura existente de la clase AppDomain en general en No entiendo Application Domains
Respuestas:
Un AppDomain básicamente proporciona una región aislada en la que el código se ejecuta dentro de un proceso.
Una forma fácil de pensar en ello es casi como un proceso más liviano dentro de su proceso principal. Cada AppDomain existe dentro de un proceso en completo aislamiento, lo que le permite ejecutar el código de forma segura (se puede descargar sin destruir todo el proceso si es necesario), con seguridad separada, etc.
En cuanto a sus detalles, si ejecuta código en 2 AppDomains diferentes dentro de un proceso, el código se ejecutará de forma aislada. Cualquier comunicación entre AppDomains se serializará o se manejará a través de MarshallByRefObject. Se comporta de manera muy similar a usar la comunicación remota a este respecto. Esto proporciona una gran cantidad de seguridad: puede ejecutar código en el que no confía y, si hace algo mal, no lo afectará.
Hay muchos más detalles en la descripción de dominios de aplicación de MSDN .
Es una capa de aislamiento proporcionada por el tiempo de ejecución de .NET. Como tal, los dominios de aplicaciones conviven en un proceso (un proceso puede tener muchos dominios de aplicaciones) y tienen su propio espacio de direcciones virtuales.
Los dominios de aplicaciones son útiles porque:
Si lo mira desde la perspectiva de los detalles internos del procesador, establece un valor diferente para el registro de segmento de código (CS). y el registro CS: IP (Instruction Pointer) es el que está en ejecución por el procesador.
(Elegí hojear la discusión relacionada con la tabla de la página por brevedad).
AppDomain marca este límite. para la seguridad del código.
La razón para dar este trasfondo es para salirse con la pregunta de este tipo: 1. ¿Cómo podemos acceder a los recursos a través de dos dominios de aplicaciones (sí, usando tuberías o algún otro mecanismo de intercambio no directamente como CS: IP no se puede configurar en algún otro dominio de aplicación? Es solo el sistema operativo el que puede hacerlo. No el CLR)
¿Podría haber varios subprocesos en el dominio de la aplicación? Técnicamente, sí, ya que el valor de CS estará en el proceso actual. puede cambiar la IP a otra cosa mediante una declaración de salto (combinación de llamada de función / goto)
¿Pueden comunicarse dos subprocesos en dos dominios de aplicaciones diferentes (No. consulte el punto 1.)
¿Pueden comunicarse dos subprocesos en el dominio de una sola aplicación (Sí, consulte el punto 2)
varias otras combinaciones de estos casos podrían responderse con poco conocimiento de cómo funciona CS: IP.
Cada aplicación que se ejecuta dentro de un proceso, AppDomain también es un proceso liviano o podemos decir unidad lógica que tiene un grupo de ensamblajes (este es un contenedor que contiene un grupo de ensamblajes) y esto existe dentro del proceso en el nivel de aislamiento del mismo proceso , esto permite ejecutar múltiples ensamblajes dentro del mismo proceso y evitar su acceso directo.
Ejecución de la aplicación Dot Net dentro de AppDomain: Una vez que se ejecuta cualquier aplicación dot net, el shell del sistema operativo carga CLR en un proceso y se crea un nuevo AppDomain en el mismo proceso y carga todos los ensamblados en el AppDomain creado, ahora desde el código de AppDomain se ejecutará.
Cuándo personalizar AppDomain: Podemos crear nuestro propio AppDomain, ahora la cuestión es en qué escenario podemos crear nuestro propio AppDomain. Supongamos que en tiempo de ejecución necesitamos agregar o eliminar los ensamblados sin interrumpir la aplicación en ejecución, luego podemos crear nuestro propio AppDomain.