2016-11-14 2 views
3

Dans notre application (solution avec 65 projets), tous les assemblys référencés sont analysés en phase d'exécution pour la présence de modules Ninject (un filtrage est appliqué) aussi). Les modules sont chargés plus tard dans le noyau Ninject et chaque module déclare des liaisons pour le noyau.La méthode n'a pas d'implémentation lors du chargement des assemblys dans un nouvel AppDomain en mode ReflectionOnly

Nous avons adopté un chargeur qui charge les assemblages référencés dans un assemblage séparé en mode réflexion seule. La différence par rapport à la façon dont Ninject peut charger les assemblages à partir du répertoire est que le répertoire peut contenir des assemblys avec des modules qui ne devraient pas être chargés. Et au tout début, tous les assemblages référencés ne sont pas chargés.

Le problème est que le loader (crédit Sacha Barber) ne peut pas charger des assemblages avec le

System.Reflection.ReflectionTypeLoadException: Unable to load one or more of the requested types. Retrieve the LoaderExceptions property for more information 

et LoaderExceptions avec une entrée:

Method 'BeforeLoad' in type 'Lekis.AppBase.Core.BLLBaseCore' from assembly 'AppBaseCore, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' does not have an implementation. 

Voici quelques faits "fun" :

  • la méthode BeforeLoad est virtuelle et une implémentation d'une méthode d'interface
  • La semaine dernière, l'exception loader disait que la méthode différente n'avait pas d'implémentation (cette méthode n'était pas virtuelle) et plus tard, quand je l'ai explicitement implémentée, le message disait que la méthode n'était pas trouvée.
  • semaine dernière, le cadre cible pour l'assemblage AppBaseCore était .NET 3.5 et 3 ensembles n'a pas réussi à charger
  • maintenant le cadre cible pour l'assemblage AppBaseCore est .NET 4 et 5 ensembles n'a pas réussi à charger
  • tout va bien avec l'application sinon

Il n'y a rien de mal (évidemment) avec les assemblages quand je les ai vérifiés avec ILSpy et ILDAsm.

À ce stade, je suis vraiment perdu et je ne sais pas comment aborder ce problème.

Toute aide est appréciée.

Merci

+1

"méthode' BeforeLoad' est virtuel et une implémentation d'une méthode d'interface ". est-ce * vraiment *, cependant? Cochez [toutes les réponses ici] (http://stackoverflow.com/questions/948785/) pour vous assurer que vous ne rencontrez pas de conflit de version/chargement.ILSpy/ILDAsm ne signalera aucun problème puisque l'assemblage est structurellement valide. –

+0

Merci, @JeroenMostert. Je vais y jeter un coup d'oeil. –

Répondre

3

répondre à ma propre question:

Lorsque l'exception a été levée, je suis allé la trace de la pile et la liste des assemblées chargées dans l'enfant AppDomain créé:

AppDomain.CurrentDomain.ReflectionOnlyGetAssemblies() 
{System.Reflection.RuntimeAssembly[15]} 
... 
[13]: {System.Data, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089} 
[14]: {System.Data, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089} 

et remarquées les deux versions de l'ensemble System.Data. La méthode en question a un paramètre de type System.Data.IDbTransaction.

Le premier a été référencé dans un projet ciblant .NET Framework 3.5. Après avoir changé à 4.0 tout fonctionne bien.

Quel problème stupide ...