AppDomain.CurrentDomain.GetAssemblies() lance System.Reflection.ReflectionTypeLoadException lors de l'utilisation de Sybase.

Question

Je pense que j'ai utilisé un modèle assez commun :

var result = from a in AppDomain.CurrentDomain.GetAssemblies()
                         from t in a.GetTypes()
                         where t.IsDefined(typeof(TAttribute), inherit)
                         select t;

Si j'appelle le code depuis Program.cs, cela fonctionne.

Aussi, si je l'appelle à partir d'un formulaire, il fonctionne - parfois, selon le formulaire. Parfois, il ne fait que lancer une erreur : Au moins un type de l'assembly ne peut pas être chargé. Récupère la propriété LoaderExceptions si tu as besoin de plus d'informations.

C'est dans les détails que se trouve l'information :

{"Le fichier ou l'assemblage \N "EntityFramework, Version=4.2.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089\" ou une dépendance de celui-ci n'a pas été trouvé. Le système ne peut pas trouver le fichier spécifié" : "EntityFramework, Version=4.2.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"}

C'est en quelque sorte un peu étonnant pour moi. Pour autant que je sache, nous n'utilisons EntityFramework nulle part, seulement Telerik comme ER.

J'ai fait un "findstr /s /i /m entityframework". . "dans les répertoires du projet.

De façon amusante, il l'a trouvé dans une dll Sybase "SQL Anywhere 12". \iAnywhere.Data.SQLAnywhere.v4.0.dll ".

ok - cela ressemble un peu à un fournisseur de données sybase sql. Mais pour autant que je puisse voir, nous n'avons pas besoin d'EntityFramework, et le projet fonctionne également comme prévu.

Comment puis-je résoudre ce problème ? Comme si je disais : Je veux analyser Appdomain, mais pas certaines dlls de tiers. Ou y a-t-il un moyen d'ignorer cette erreur ?

Answer 1

L'analyse de l'ensemble du domaine de l'application de cette façon va scanner toutes les dll qui sont chargées et tous les types de dll seront chargés même s'ils ne sont pas utilisés dans votre application. Je ne parle pas couramment l'allemand mais je suppose que l'erreur signifie que la dll EF n'a pas été trouvée. Il est nécessaire de charger une classe qui n'est pas utilisée par votre code et qui est déclarée dans une dll qui est chargée dans le domaine de l'application et qui nécessite EF. Vous dites que vous utilisez Telerik, peut-être a-t-il des contrôles qui utilisent directement EF ?

La solution simple, si vous voulez analyser uniquement vos dlls, serait d'introduire une convention pour les noms d'assemblage. Disons que toutes vos dlls seront nommées OfflerCompany.ProjectName.Something et rechercher le nom de la dll pour OfflerCompany .

Notez également que les dlls sont chargées paresseusement dans le domaine de l'application, donc si vous vous attendez à ce que toutes vos dlls soient présentes, vous risquez d'être déçu (elles peuvent déjà être présentes si elles ont toutes été utilisées directement ou pas au moins une fois).

Vous pouvez envisager de créer un fichier de configuration contenant les noms de toutes les dll qui doivent être analysées. C'est la solution la plus propre et la plus transparente que je préfère.