Pase y ejecute el delegado en AppDomain separado

Aunque puedes hacer una llamada a un delegado que será manejada por un AppDomain separado, personalmente siempre he utilizado el método 'CreateInstanceAndUnwrap' que crea un objeto en el dominio de la aplicación extranjera y devuelve un proxy a él.

Para que esto funcione su objeto tiene que heredar de MarshalByRefObject.

Aquí hay un ejemplo:

    public interface IRuntime
    {
        bool Run(RuntimesetupInfo setupInfo);
    }

    // The runtime class derives from MarshalByRefObject, so that a proxy can be returned
    // across an AppDomain boundary.
    public class Runtime : MarshalByRefObject, IRuntime
    {
        public bool Run(RuntimeSetupInfo setupInfo)
        {
            // your code here
        }
    }

    // Sample code follows here to create the appdomain, set startup params
    // for the appdomain, create an object in it, and execute a method
    try
    {
        // Construct and initialize settings for a second AppDomain.
        AppDomainSetup domainSetup = new AppDomainSetup()
        {
            ApplicationBase = AppDomain.CurrentDomain.SetupInformation.ApplicationBase,
            ConfigurationFile = AppDomain.CurrentDomain.SetupInformation.ConfigurationFile,
            ApplicationName = AppDomain.CurrentDomain.SetupInformation.ApplicationName,
            LoaderOptimization = LoaderOptimization.MultiDomainHost
        };

        // Create the child AppDomain used for the service tool at runtime.
        childDomain = AppDomain.CreateDomain(
            "Your Child AppDomain", null, domainSetup);

        // Create an instance of the runtime in the second AppDomain. 
        // A proxy to the object is returned.
        IRuntime runtime = (IRuntime)childDomain.CreateInstanceAndUnwrap(
            typeof(Runtime).Assembly.FullName, typeof(Runtime).FullName);

        // start the runtime.  call will marshal into the child runtime appdomain
        return runtime.Run(setupInfo);
    }
    finally
    {
        // runtime has exited, finish off by unloading the runtime appdomain
        if(childDomain != null) AppDomain.Unload(childDomain);
    }

En el ejemplo anterior, está codificado para ejecutar un método ' Run ' pasando información de configuración y completando el El método Run se determina para indicar que todo el código en el AppDomain hijo se ha completado la ejecución, por lo que tenemos un bloque final que garantiza que el AppDomain se descargue.

A menudo es posible que desee tener cuidado en qué tipos coloca en qué ensamblados: puede usar una interfaz y colocarla en un ensamblado separado del que dependen tanto el llamador (nuestro código que configura el appdomain y lo llama) como el implementador (la clase de tiempo de ejecución). Este IIRC permite que el AppDomain padre para cargar solo el ensamblado que contiene la interfaz, mientras que el appdomain hijo cargará tanto el ensamblado que contiene el tiempo de ejecución como su dependencia (el ensamblado IRuntime). Cualquier tipo definido por el usuario que sea utilizado por la interfaz de IRuntime (por ejemplo, nuestra clase RuntimeSetupInfo) debería normalmente ser colocado en el mismo ensamblado que IRuntime. Además, tenga cuidado de cómo define estos tipos definidos por el usuario : si son objetos de transferencia de datos (como probablemente lo sea RuntimeSetupInfo), probablemente debería marcar ellos con el atributo [serializable] - para que se pase una copia del objeto (serializada desde el appdomain padre al hijo). Desea evitar que las llamadas se marshalled de un appdomain a otro, ya que esto es bastante lento. Pasar DTOs por valor (serialización) significa que acceder a los valores en el DTO no incurre en una llamada de apartamento cruzado (ya que el appdomain hijo tiene su propia copia del original). Por supuesto, esto también significa que los cambios de valor no se reflejan en el appdomain padre DTO original.

Como está codificado en el ejemplo, el appdomain padre terminará cargando tanto los ensamblados IRuntime como Runtime, pero eso se debe a que en la llamada a CreateInstanceAndUnwrap estoy usando typeof(Runtime) para obtener el nombre del ensamblado y el nombre del tipo completamente calificado. En su lugar, podría codificar o recuperar estas cadenas de un archivo, lo que desacoplaría la dependencia.

También hay un método en AppDomain llamado 'DoCallBack' que parece que permite llamar a un delegar en un AppDomain extranjero. Sin embargo, el tipo de delegado que toma es de tipo 'CrossAppDomainDelegate'. La definición de la cual es:

public delegate void CrossAppDomainDelegate()

Por lo tanto, no le permitirá pasar ningún dato en él. Y, como nunca lo he usado, no puedo decirte si hay algún truco en particular.

También, recomendaría buscar en la propiedad LoaderOptimization. Lo que establece esto, puede tener un efecto significativo en el rendimiento, ya que algunos ajustes de esta propiedad fuerzan la nuevo appdomain para cargar copias separadas de todos los ensamblajes (y JIT ellos, etc.) incluso si (IIRC) la asamblea está en el GAC (es decir, esto incluye asambleas CLR). Esto puede darle un rendimiento horrible si utiliza un gran número de ensamblados de su appdomain hijo. Por ejemplo, he usado WPF desde appdomains hijos que causaron grandes retrasos de inicio para mi aplicación hasta que configuré una política de carga más adecuada.