Proceso de Sustitución.Comience con AppDomains

Los dominios de aplicación y la interacción entre dominios es un asunto muy delgado, por lo que uno debe asegurarse de que realmente entiende cómo funcionan las cosas antes de hacer nada... Mmm... Digamos, "no estándar": -)

En primer lugar, su método de creación de flujo realmente se ejecuta en su dominio" predeterminado " (surprise-surprise!). ¿Por qué? Simple: el método que pasa a AppDomain.DoCallBack está definido en un objeto AppDomainDelegateWrapper, y ese objeto existe en su dominio predeterminado, por lo que es donde se ejecuta su método. MSDN no dice acerca de esta pequeña "característica", pero es bastante fácil de comprobar: solo establece un punto de interrupción en AppDomainDelegateWrapper.Invoke.

Así que, básicamente, tienes que arreglártelas sin un objeto "wrapper". Utilice el método estático para el argumento de DoCallBack.

Pero, ¿cómo pasa su argumento "func" en el otro dominio para que su método estático pueda recogerlo y ejecutarlo?

La forma más evidente es usar AppDomain.SetData, o puedes rodar la tuya propia, pero independientemente de cómo lo hagas exactamente, hay otra problema: si" func " es un método no estático, entonces el objeto en el que está definido debe pasarse de alguna manera al otro appdomain. Se puede pasar por valor (mientras que se copia, campo por campo) o por referencia (creando una referencia de objeto de dominio cruzado con toda la belleza de la comunicación remota). Para hacer lo anterior, la clase tiene que ser marcada con un atributo [Serializable]. Para hacer esto último, tiene que heredar de MarshalByRefObject. Si la clase no es ninguna de las dos, se lanzará una excepción al intentar pasar el objeto al otro dominio. Sin embargo, tenga en cuenta que pasar por referencia prácticamente elimina toda la idea, porque su método seguirá siendo llamado en el mismo dominio en el que existe el objeto, es decir, el predeterminado.

Concluyendo el párrafo anterior, le quedan dos opciones: pasar un método definido en una clase marcada con un atributo [Serializable] (y tenga en cuenta que el objeto se copiará), o pasar un método estático. Sospecho que, para sus propósitos, necesitará el ex.

Y por si acaso se le ha escapado la atención, me gustaría señalar que su segunda sobrecarga de RunInAppDomain (la que toma Action) pasa un método definido en una clase que no está marcada [Serializable]. ¿No ves ninguna clase allí? No tiene que hacerlo: con delegados anónimos que contienen variables enlazadas, el compilador creará una para usted. Y resulta que el compilador no se molesta en marcar esa clase autogenerada [Serializable]. Desafortunado, pero esto es la vida :-)

Habiendo dicho todo eso (muchas palabras, ¿no? :- ), y asumiendo su voto de no pasar ningún método no estático y no-[Serializable], aquí están sus nuevos métodos RunInAppDomain:

    /// <summary>
    /// Executes a method in a separate AppDomain.  This should serve as a simple replacement
    /// of running code in a separate process via a console app.
    /// </summary>
    public static T RunInAppDomain<T>(Func<T> func)
    {
        AppDomain domain = AppDomain.CreateDomain("Delegate Executor " + func.GetHashCode(), null,
            new AppDomainSetup { ApplicationBase = Environment.CurrentDirectory });

        try
        {
            domain.SetData("toInvoke", func);
            domain.DoCallBack(() => 
            { 
                var f = AppDomain.CurrentDomain.GetData("toInvoke") as Func<T>;
                AppDomain.CurrentDomain.SetData("result", f());
            });

            return (T)domain.GetData("result");
        }
        finally
        {
            AppDomain.Unload(domain);
        }
    }

    [Serializable]
    private class ActionDelegateWrapper
    {
        public Action Func;
        public int Invoke()
        {
            Func();
            return 0;
        }
    }

    public static void RunInAppDomain(Action func)
    {
        RunInAppDomain<int>( new ActionDelegateWrapper { Func = func }.Invoke );
    }

Si todavía estás conmigo, aprecio : -)

Ahora, después de pasar tanto tiempo arreglando ese mecanismo, les voy a decir que no tenía propósito de todos modos.

La cosa es, AppDomains no le ayudará para sus propósitos. Solo se ocupan de los objetos administrados, mientras que el código no administrado puede filtrarse y estrellarse todo lo que quiera. El código no administrado ni siquiera sabe que hay cosas como appdomains. Solo sabe de procesos.

Así que, al final, tu mejor opción sigue siendo tu solución actual: solo genera otro proceso y sé feliz. Y, estaría de acuerdo con las respuestas anteriores, no tiene que escribir otra aplicación de consola para cada caso. Simplemente pase un nombre completo de un método estático y haga que la aplicación de consola cargue su ensamblado, cargue su tipo e invoque el método. En realidad, puede empaquetarlo bastante bien de la misma manera que lo intentó con AppDomains. Puede crear un método llamado algo así como "RunInAnotherProcess", que examinará el argumento, obtendrá el nombre completo del tipo y el nombre del método (mientras se asegura de que el método sea estático) y generará la aplicación de consola, que hará el resto.