Remplacement De Processus.Démarrer avec les domaines d'application

Domaines d'Application et les interactions entre les domaines est un très mince affaire, donc on doit s'assurer qu'il comprend vraiment comment les choses fonctionnent avant de faire quoi que ce soit... heu... disons, "non-standard" 🙂

Tout d'abord, le flux de création de la méthode exécute sur "par défaut" du domaine (surprise, surprise!). Pourquoi? Simple: la méthode que vous passez dans AppDomain.DoCallBack est définie sur une AppDomainDelegateWrapper objet, et cet objet existe sur votre domaine par défaut, c'est donc là que sa méthode est exécutée. MSDN ne pas dire à propos de cette petite "feature", mais il est assez facile à vérifier: il suffit de mettre un point d'arrêt dans AppDomainDelegateWrapper.Invoke.

Donc, fondamentalement, vous avez à faire sans un "wrapper" de l'objet. Utiliser la méthode statique pour DoCallBack de l'argument.

Mais comment voulez-vous passer vos "func" argument dans l'autre domaine, de sorte que votre méthode statique peut le ramasser et de les exécuter?

La manière la plus évidente consiste à utiliser AppDomain.SetData, ou vous pouvez rouler votre propre, mais quel que soit exactement comment vous le faites, il y a un autre problème: si "func" est un non-statique méthode, l'objet qu'il doit être en quelque sorte passé dans l'autre domaine d'application. Il peut être passé par valeur (alors que c'est copié, champ par champ) ou par référence (la création d'un inter-domaine objet de référence avec toute la beauté de l'accès distant). Pour les anciens, la classe doit être marqué avec un [Serializable] attribut. Pour faire ci, il doit hériter de MarshalByRefObject. Si la classe n'est ni de, une exception sera levée lors de la tentative de faire passer l'objet à l'autre domaine. Gardez à l'esprit, cependant, que le passage par référence assez bien tue l'idée, parce que votre méthode s'appelle toujours sur le même domaine que l'objet existe - ce qui est, celui par défaut.

La conclusion du paragraphe ci-dessus, il vous reste deux options: soit de passer à une méthode définie dans une classe marquée avec un [Serializable] attribut (et de garder à l'esprit que l'objet sera copié), ou de passer d'une méthode statique. Je soupçonne que, pour votre application, vous aurez besoin de l'ancien.

Et juste au cas où il a échappé à votre attention, je tiens à souligner que votre deuxième surcharge de RunInAppDomain (celui qui prend Action) passe une méthode définie dans une classe qui n'est pas marquée [Serializable]. Ne vois pas la classe? Vous n'avez pas à: avec les délégués anonymes contenant des variables liées, le compilateur va créer un pour vous. Et il se trouve que le compilateur n'a pas pris la peine de marque générée automatiquement classe [Serializable]. Malheureux, mais c'est la vie 🙂

Après avoir dit tout cela (beaucoup de mots, n'est-ce pas? :-), et en supposant que votre vœu de ne pas passer n'importe quel non-statique et non-[Serializable] méthodes, voici votre nouveau RunInAppDomain méthodes:

    ///<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 vous êtes toujours avec moi, j'apprécie 🙂

Maintenant, après tant de temps passé sur la fixation de ce mécanisme, je vais vous dire que c'est inutile de toute façon.

La chose est, les domaines d'application ne sera pas vous aider pour vos besoins. Ils ne prennent soins d'objets gérés, tandis que le code non managé peut fuir et crash tout ce qu'il veut. Code non managé ne sait même pas il ya des choses telles que les domaines d'application. Il ne sait que sur les processus.

Donc, en fin de compte, votre meilleure option reste de votre solution actuelle: il suffit de générer un autre processus et être heureux à ce sujet. Et, je suis d'accord avec les réponses précédentes, vous n'avez pas à écrire une autre console application pour chaque cas. Il suffit de passer le nom complet d'une méthode statique, et que la console de chargement des applications de votre assemblée, charge de votre type, et d'invoquer la méthode. Vous pouvez réellement paquet assez soigneusement dans un très peu de la même manière que vous avez essayé avec des domaines d'application. Vous pouvez créer une méthode appelé quelque chose comme "RunInAnotherProcess", qui traitera de l'argument le nom complet du type et de la méthode nom de celui-ci (tout en s'assurant que la méthode est statique) et donnera lieu à l'application de console, qui fera le reste.

Avez-vous envisagé de l'ouverture d'un tuyau entre l'application principale et les sous applications? De cette façon, vous pouvez passer plus d'informations structurées entre les deux applications sans analyse standard de sortie.