MEF: "Impossible de charger un ou plusieurs des types demandés Récupérer les LoaderExceptions pour plus d'informations"

Question

Scénario: J'utilise Managed Extensibility Framework pour charger des plugins (exports) à l'exécution sur la base d'un contrat d'interface défini dans une DLL distincte . Dans ma solution Visual Studio, j'ai 3 projets différents: L'application hôte, une bibliothèque de classes (définissant l'interface - "IPlugin") et une autre bibliothèque de classes implémentant l'interface (l'export - "MyPlugin.dll"). L'hôte recherche les exportations dans son propre répertoire racine. Pendant les tests, je compile l'ensemble de la solution et copie Plugin.dll du dossier bin de bibliothèque de plugins/release vers le répertoire de débogage de l'hôte afin que DirectoryCatalog de l'hôte trouve et pouvoir l'ajouter au CompositionContainer. Plugin.dll n'est pas automatiquement copié après chaque reconstruction, donc je le fais manuellement chaque fois que j'ai apporté des modifications au contrat/à l'implémentation.

Cependant, deux ou trois fois je l'ai exécuté l'application hôte sans avoir copié (un jour) plugin.dll en premier lieu, et il a jeté une exception lors de la composition:

Unable to load one or more of the requested types. Retrieve the LoaderExceptions for more information

Ceci est Bien sûr, en raison du fait que le Plugin.dll, il essaie d'importer à partir d'implémente une version différente de IPlugin, où les signatures de propriété/méthode ne correspondent pas. Bien qu'il soit facile d'éviter cela dans un environnement contrôlé et surveillé, en évitant simplement (duh) les implémentations IPlugin obsolètes dans le dossier plugin, je ne peux pas me fier à de telles suppositions dans l'environnement de production, où des plugins hérités pourraient être rencontrés.

Le problème est que cette exception gomme effectivement toute l'action Compose et que les exportations sont importées. J'aurais préféré que les implémentations IPlugin non concordantes soient simplement ignorées, de sorte que d'autres exportations dans le (s) catalogue (s), implémentant la version correcte d'IPlugin, sont toujours importées.

Existe-t-il un moyen d'accomplir ceci? Je pense soit plusieurs options possibles:

• Il y a un drapeau à mettre sur le CompositionContainer (« ignorer les importations ne ») avant ou lors de l'appel Compose
• Il y a un drapeau similaire à indiquer sur la <ImportMany()> attribut
• Il est un moyen de « crochet » sur le processus d'itération sous-jacente Compose(), et être en mesure de traiter chaque (échec) importation individuellement
• utilisant le nom forte signature d'une certaine façon que chercher des importations d'application de la version actuelle de IPlugin

Idées?

Answer 1

J'ai également rencontré a similar problem.

Si vous êtes sûr de vouloir ignorer ces "mauvais" assemblages, la solution consiste à appeler AssemblyCatalog.Parts.ToArray() juste après la création de chaque catalogue d'assemblage. Cela déclenchera le ReflectionTypeLoadException que vous mentionnez. Vous avez alors une chance d'attraper l'exception et d'ignorer le mauvais assemblage. Lorsque vous avez créé des objets AssemblyCatalog pour tous les «bons» assemblages, vous pouvez les agréger dans un AggregateCatalog et les transmettre au constructeur CompositionContainer.

Answer 2

Ce problème peut être causé par plusieurs facteurs (des exceptions sur les assemblées chargées), comme l'exception dit, regardez la ExceptionLoader à (je l'espère) se faire une idée

Un autre problème/solution que je trouve, est Si vous n'utilisez pas DirectoryCatalog, si vous ne spécifiez pas le deuxième paramètre "searchPattern", MEF chargera TOUTES les DLL dans ce dossier (y compris les tiers), et commencera à rechercher les types d'exportation, qui peuvent également causer ce problème, une solution consiste à avoir un nom de convention sur tous les assemblys qui exportent les types, et spécifier que dans le constructeur DirectoryCatalog, j'utilise * _Plugin.dll, de cette façon MEF ne chargera que les assemblys contiennent exporté des types

Dans mon cas MEF chargeait une dll NHibernate et lancer une erreur de version de montage sur le LoaderException (cette erreur peut se produire avec l'une des dll dans le répertoire), cette approche a résolu le problème

Answer 3

ici est un exemple des méthodes mentionnées ci-dessus:

var di = new DirectoryInfo(Server.MapPath("../../bin/")); 

     if (!di.Exists) throw new Exception("Folder not exists: " + di.FullName); 

     var dlls = di.GetFileSystemInfos("*.dll"); 
     AggregateCatalog agc = new AggregateCatalog(); 

     foreach (var fi in dlls) 
     { 
      try 
      { 
       var ac = new AssemblyCatalog(Assembly.LoadFile(fi.FullName)); 
       var parts = ac.Parts.ToArray(); // throws ReflectionTypeLoadException 
       agc.Catalogs.Add(ac); 
      } 
      catch (ReflectionTypeLoadException ex) 
      { 
       Elmah.ErrorSignal.FromCurrentContext().Raise(ex); 
      } 
     } 

     CompositionContainer cc = new CompositionContainer(agc); 

     _providers = cc.GetExports<IDataExchangeProvider>();