vérifier qu'une dll implémente une interface

Bonjour,

je suis en train de mettre en place ce que j'appelle un moteur de plug-ins.
L'idée est la suivante:
J'ai un programme principal qui propose une interface plublique. On l'appelera IMyInterface. Cette interface définit quelques fonctions.
A côté de ce programme principal, j'ai plusieurs bibliothèques (libraries). Chaque bibliothèque possède une classe qui implémente IMyInterface.
Les binaires du programme principal (.exe) et des bibliothèques (.dll) sont générés dans le même répertoire bin.

Ce que je veux faire c'est: au lancement de l'exécutable, il regarde toutes les dlls présentes dans le répertoire bin, et charge uniquement celles qui implémentent IMyInterface.

J'ai réussi à lister toutes les dlls du répertoire bin. Ce que je ne parviens pas à faire c'est vérifier quelles sont celles qui implémentent IMyInterface. Comment puis-je faire?

salut

2 solutions :

Framework .Net 4.0 : Utilisation de MEF (Managed Extension Framework)
qui te permet de faire cela...

Sinon, il faut monter une DLL (LoadAssembly) et ensuite, utiliser les fonctions de reflections pour savoir si la dll contient une classe implémentant ton interface.

Le seul "hic" est que tu vas "monter" toutes les DLL pour les tester et que, à moins de passer dans des domaines d'applications différents, si une DLL n'est pas "éligibles", elle aura été monté et donc, si une autre dll que tu montes s'appuye sur cette dll, tu vas l'avoir montée 2 fois et donc, éventuellement avoir des soucis...

C'est pour cette raison que je te conseille fortement MEF dans ton cas de figure...

Il existe des exemples sur le net pour monter une DLL et instancier une classe d'une DLL correspondant aux critères qui vont bien en terme d'interface implémentée :)

Ha oui, j'ai oublié de spécifier que je suis restreint au framework 3.5 (ça ne dépend pas de moi, on a des soucis avec le framework 4; rien que si on l'installe, sans même l'utiliser je veux dire, on a des problèmes).

Donc ok, je vais regarder du côté de la reflection. Si jamais tu as des liens intéressants sur le sujet, je suis preneur :)

:merci:

Bonjour

Premièrement, c'est un truisme, mais il convient de le rappeler une DLL n'implémente pas d'interface, seule les classes le font.

Tu peux donc charger tes assemblyes, balayer l'ensemble des classes qu'elles contiennent, et vérifier si l'interface est implémentée pour chaque classe avec par exemple un code comme celui ci :

Code:

---

1 2 3 4

public bool ImplementInterface(Type typeToTest, Type interfaceToTest) { return interfaceToTest.IsAssignableFrom(typeToTest); }

---

pour tester chaque classe exportée par une assembly, c'est aussi très simple :

Code:

---

1 2 3 4 5 6 7 8 9 10 11

public void testAllClasses(Assembly assembly) { Type[] types = assembly.GetExportedTypes(); foreach (Type atype in types) { if (atype.IsClass) { bool implementInterface = ImplementInterface(atype, typeof(MyInterface)); } } }

---

Ceci dit, d'une manière générale, pour les plug-in en dotNet, l'usage habituel est d'associer à l'interface de Plugin un jeu de classes héritant de Attribute permettant de récupérer des infos sur les classes en question sans avoir à les instancier (description, etc .....). ces classes Attribute peuvent aussi être associée au niveau de l'assembly (pour dire si une assembly contient par exemple, au moins une classe susceptible d'être un plug-in, etc ...)

bluedeep, comment fais-tu cette association Classe Attribute maison avec l'assembly ?

Créer un moteur de plugins performant et sûr n'est pas quelque chose de facile. Lister des dll et instancier une classe implémentant une interface n'est que la partie emergée de iceberg. Tu as des problèmatiques de sécurité, d'isolation des addins par rapport à l'application principale, de versionning, etc.

Je te conseil fortement d'utiliser un moteur existant.

Une des nouveauté du framework 3.5 est la présence d'un moteur d'addin dans le namespace System.AddIn. Tu as un article sur le sujet ici (plus la doc officielle sur MSDN):
http://badger.developpez.com/tutorie...framework-3-5/


MEF est aussi une possibilité mais n'est pas un véritable moteur d'addin comme peut l'être System.Addin. C'est un framework de composition (utilisé par Visual Studio 2010 notamment). Il existe une version de MEF pour le framework 3.5 dont les sources sont disponibles sur le site codeplex:
http://mef.codeplex.com/

Les deux n'adressent pas les mêmes besoins, à toi de voir.

Citation:

---

Envoyé par theMonz31

bluedeep, comment fais-tu cette association Classe Attribute maison avec l'assembly ?

---

Tu décrit un attribut "classique" en spécifiant un usage "Assembly":

Code:

---

1 2 3 4 5

[AttributeUsage(AttributeTargets.Assembly)] public class MyAssemblyMetaDataAttribute : Attribute {   }

---

Ensuite, les attributs assembly se mettent dans le AssemblyInfo.cs (dans Properties), en les préfixant via "assembly" :

Code:

---

[assembly: MyAssemblyMetaData()]

---

Et pour les récupérer, tu utilises classiquement le GetCustomAttributes, mais appelé au niveau de l'instance Assembly.

Merci Bluedeep

J'aurais appris quelque chose aujourd'hui (ou plus exactement une utilisation que je ne faisais pas spécialement avant celà)

Badger_Man, le système d'Add-in est-il vraiment bien ?

Quel avantage ou inconvénient par rapport à l'aspect Add-in de MEF ? (en dehors de la version du framework cible)...

Wow ^_^

Ton tuto est génial tha_badger. Il faut que je regarde un peu plus en détails, mais j'ai l'impression que ça répond bien à mes besoins. Juste une question: moi je suis obligé de tout mettre dans le même répertoire: le prog principal (c'est lui que tu appelles "hôte" dans ton exemple?), les addins, les ressources, etc. Penses-tu que l'on peut adapter ton exemple de façon à ce que cette contrainte soit respectée?

Sinon, je ne sais pas quelle solution est la plus appropriée dans mon cas. CE que je veux faire, en fait, c'est grosso-modo:
- un prog pricipal, qui:
-> possède une ihm pour afficher les résultats des addins
-> propose une série de classe "outils", en autres l'accès à une bdd (par odbc)
- des addins qui (type D.P command), qui doivent juste implémenter 3 choses: CommandName(), CommandDescription(), et Execute(). Execute() renvoie un simple DataSet qui sera affiché dans par le prog principal.

juste pour info R0d,

si le nombre d'addins est maitrisé dès le début et que c toi qui les développe, peut-etre que la gestion d'add-in n'est pas complètement utile.

Le mécanisme des add-in, c'est vraiment utile si tu ouvres ton application aux autres... ou bien que tu es "sur" que tu vas ajouter des fonctionnalités "addinable" dans ton application...

Ou bien aussi que tu ne veux pas t'emmerder à recompiler ton application à chaque fois que tu ajoutes un add-in alors que l'hôte, lui, ne changera vraiment pas souvent...

Vivi, l'idée c'est de mettre en place un système super simple pour aider nos ingénieurs terrains (qui sont de très piètres programmeurs).
Donc mon idée c'est, une fois que mon système sera mis en place, fournir un projet "template" pour un nouvel add-in, pour qu'ensuite les ingés puissent faire eux-même leur fonctions.
Donc voilà, je ne sais pas à l'avance combien j'aurai d'addin, et de plus, il faut que ce soit le plus simple possible d'en ajouter de nouveaux (puisque ce seront des non-développeurs qui vont le faire).

Si c'est aussi simple sans doute vaut-il mieux partir sur du MEF.