C#, MAF, Gestion des exceptions non gérées dans AppDomain séparé

Question

Ok, donc j'ai une application MAF qui charge chaque addin à l'intérieur d'un domaine d'application distinct. Cela fonctionne fantastique pour ce dont j'ai besoin car il me permet de décharger dynamiquement et recharger mes addins à l'exécution.

Le problème est, je dois être en mesure de prendre une exception non gérée chez l'enfant appdomain, attraper, puis laisser que appdomain échouer gracieusement sans arrêter la appdomain mère

Comment puis-je faire de manière ? Cela semble être une tâche triviale et l'un des principaux avantages de l'utilisation de domaines d'application isolés ...

Answer 1

Je pense que ma réponse à cette question similaire devrait vous aider:

Application crash when anoter domain throws exception

Laissez-moi savoir si vous avez besoin de plus d'informations.

Answer 2

Autant que je sache, vous ne pouvez pas faire cela hors de la boîte. Vous pouvez utiliser des classes abstraites pour les vues de complément et ajouter des blocs try/catch partout combinés avec le modèle Template Method (c'est-à-dire la méthode Read dans la vue abstraite complémentaire appelle une fonction ReadCore virtuelle que le complément doit implémenter). Vous ne pouvez toujours pas gérer les exceptions non gérées générées à partir des fils enfants de l'enfant AppDomain. Ceux-ci vont planter votre application.

Encore une fois, autant que je sache, il y a deux façons de gérer ce problème:

1. Utiliser l'isolation des processus. C'est le seul moyen de s'assurer que les compléments ne planteront pas l'hôte. Suivez l'approche décrite dans l'article Using AppDomain Isolation to Detect Add-In Failures du blog de l'équipe System.AddIn. Cette approche ne peut pas empêcher votre application de se bloquer, mais votre application saura quel complément a provoqué le blocage. Il s'agit d'informations précieuses car votre application peut alors désactiver les compléments instables et éviter de les charger au prochain démarrage. Ou l'application peut informer l'utilisateur et le laisser décider quoi faire.

Notez que ces deux sont complémentaires. Vous pouvez commencer avec 2. puis charger des compléments instables sur différents processus.

Answer 3

Remonté aller avec une approche qui semble fonctionner beaucoup aujourd'hui, même si je reste encore un peu de creuser à faire avant que je trouve les ramifications de cette approche ...

Le blog suivant a aidé énormément: http://ikickandibite.blogspot.com/2010/04/appdomains-and-true-isolation.html

J'ai simplement permis à l'héritage politique d'exception non gérée dans le app.config:

(qui, comme votre information, est toujours disponible même dans 4,5 .Net, que j'étais préoccupé)

<?xml version="1.0" encoding="utf-8" ?> 
<configuration> 
    <startup> 
     <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.5" /> 
    </startup> 
    <runtime> 
     <legacyUnhandledExceptionPolicy enabled="true"/> 
    </runtime> 
</configuration> 

... De quel point je peux utiliser l'événement AppDomain.UnhandledException pour intercepter une exception non gérée et décharger le sous-domaine ... (notez que je dis 'intercepter' ici vaguement ... Je suis toujours pas 'attraper' l'exception, juste en en notant un déchargement de l'addin dans le processus)

Collection<AddInToken> tokens = AddInStore.FindAddIns(typeof(IApplicationAddIn), pipelineStoreLocation, addInPath); 

foreach (AddInToken token in tokens) 
{ 
    AppDomain domain = AppDomain.CreateDomain(token.Name); 
    domain.UnhandledException += (sender, args) => 
     { 
      AppDomain _domain = (AppDomain) sender; 
      AppDomain.Unload(_domain); 
     }; 
    Console.WriteLine("Initializing add-in '{0}'", token.Name); 
    IAddIn addin = token.Activate<IAddIn>(domain); 

    try 
    { 
     addin.Initialize(this); 
    } 
    catch (Exception ex) 
    { 
     Console.WriteLine("Problem initializing add-in '{0}': {1}", token.Name, ex.Message); 
    } 
}