Execution de code au chargement d'une assembly

Salut à tous,

J'aurai aimé savoir si quelqu'un connaissait le moyen d'exécuter du code "automatiquement" au chargement d'une assembly?

Je faisait ça en C++ en utilisant le DllMain pour initialiser mes plugins. Ça marchait vraiment bien et là j'aimerai reproduire le même fonctionnement en C#.

J'ai lu plusieurs articles qui disent que DllMain n'est pas disponible en C# et que même si je fait du C++ managé je ne pourrai pas exécuter du code managé dans mon DllMain...

Bref j'en suis venu à tester différentes approches à coup de variables statiques en espérant que que cela appellerait le constructeur de ma classe, mais sans succès... J'ai pensé également a une approche à grand coups d'attributes mais je vois pas trop comment je pourrai faire ça.

Si quelqu'un a une petite idée, je suis partant :)

Merci d'avance.

Tu peux ajouter un constructeur statique dans tes classes, il sera appelé avant toute autre méthode/attribut/propriété de cette classe.

Code:

---

1 2 3 4

static NomDeLaClasse() { // Initialisation des membres statiques }

---

J'ai essayé cette approche aussi, mais le constructeur statique n'est pas appelé tant que je ne me sert pas de ma classe (et je ne suis pas sensé m'en servir directement étant donné que c'est un plugin).

salut

je comprends pas bien ton problème... et surtout le pourquoi ?

Une assembly, c'est juste une librairie qui contient des classes.. quand tu "loades" une assembly, tu te "contentes" de la monter en mémoire et c'est tout (c'est d'ailleurs ce que l'on fait lorsqu'on charge une dll en C++)

Après, je ne vois pas pourquoi "executer du code automatiquement" lors d'un load d'une assembly... Si tu charges un plug-in via une assembly, beh, tu vas instancier une classe à un moment ou un autre :)

non ?

Dans quel cas as tu "aboslument" besoin d'un tel comportement ? je suis curieux d'en connaitre l'origine :)

The Monz, Toulouse

Bah l'idée est très simple:

Tu laisse à la charge des plugins le soin de s'enregistrer à l'endroit qu'ils veulent dans ton application.

Du côté de ton Core, tu te contente d'exposer des points d'accroche.

Pour la petite histoire:

J'ai du refaire un serveur http en c++ en projet à l'école, et notre système de plugin fonctionnait selon ce modèle:

* Dans ta dll de plugin, tu mettais une instance de ta classe en globale statique
* Au chargement de ta dll (LoadLibrary), la globale statique était instanciée
* Dans le constructeur de ta classe de plugin, tu pouvais t'enregistrer aux différents points mis à disposition par ton core ou effectuer d'autres initialisations et cela, sans aucune intervention de la part du Core autre que de loader la DLL

Avec ce fonctionnement, le chargement de tes plugins se résumait à faire des LoadLibrary (plus besoin de recupérer des méthodes statiques à appeler pour faire ce travail ou de passer par la fameuse méthode du GetInstance en statique). Le gros intérêt de cette méthode, c'est qu'elle permettait également de manière très simple à un plugin polymorphique de s'enregistrer sur plusieurs points d'accroche dans le cas où tu voudrais proposer plusieurs services en factorisant le code et sans gérer d'exception côté Core.


Malheureusement cette approche n'est plus possible en C# vu qu'il n'y a pas de globales, qu'il est impossible d'utiliser le DllMain, de setter un EntryPoint et que les constructeurs statiques ne sont appelés que lorsque l'on instancie réellement la classe.

Voila pourquoi je recherche un moyen d'exécuter du code de mon assembly au load de ma Dll :)

Alors il y a une technique qui peut t'intéresser. Elle implique d'utiliser un attribut personnalisé dans tes plugins.
Tu décores la classe principale à charger de chaque plugin avec ton attribut nommé par exemple LoadAttribut (pour faire court), quand tu vas loader la dll pour vérifier qu'une des classes contient bien un LoadAttribut, tu vas parcourir l'ensemble des classes de l'assembly et rechercher les attributs personnalisés. Une fois trouvée la bonne classe, si tu fais un

Code:

---

monTypeTrouvé.GetCustomAttribute(typeof(LoadAttribut))

---

Le constructeur de l'attribut sera automatiquement appelé et donc tu peux mettre dans ce constructeur les initialisations que tu souhaites faire.

Merci pour cette proposition mais dans ce cas, autant invoquer une méthode statique définie arbitrairement, ça épargne d'écrire le code de l'attribut non?
Et dans tout les cas, ça force le Core à faire une action spécifique sur la DLL autre que de la loader.

Mais après avoir pas mal cherché, j'ai vraiment l'impression que ce que je faisait en C++ ne sera plus possible à faire en C#.
Si seulement j'avais pu definir un petit EntryPoint...

salut

enfin, quelque part, un entryPoint, c'est ni plus ni moins qu'un point d'accès qui était défini dans le mode DLL ancienne version...

Que tu n'es pas cela en .Net , ca ne me choque pas dans la mesure ou tu peux très bien refaire ce mécanisme...

Et le fait que ton "core" appel une méthode du plug-in pour que celui ci s'enregistre aux différents services du core, ca ne me choque pas non plus...

Vu que c'est le core qui charge les librairies, je ne trouve pas cela abérant qu'une fois une librairie chargé, il appelle une méthode "spécifique" que cette librairie ce doit d'avoir implémenter (donc, une interface type plug-in)

Un certain nombre de chose "ont" disparu avec .Net... le modele Doc & View n'existe plus dans les templates du compilo... c'est maintenant à toi de le faire... est-ce mieux, moins bien... je ne sais pas, c'est juste différent.

C'est pareil pour les DLL...

The Monz, Toulouse

Je suis plutôt d'accord avec The Monz. Je trouve même plutôt normal de normaliser ce que font les DLL via des interfaces, pour que le core ne se trouve pas en un état indéfini à cause d'une DLL.

Si ça peut t'aider, tu peux jeter un oeil à ce tuto: http://badger.developpez.com/tutorie...framework-3-5/

Tu y trouveras peut-être des éléments de réponse...

@theMonz31:
Justement j'essaye d'éviter autant que possible de refaire des mécanismes. Si je peux trouver un moyen de faire ce que je veux automatiquement, ça me plait toujours plus que d'en réinventer à chaque fois.

@zoubidaman:
A aucun moment ton application ne se retrouve dans un état indéfini: Chaque plugin qui est chargé est responsable de se hooker aux endroits qui lui sont utiles. Dans tous les cas, si ton plugin doit se hooker il doit respecter une interface, et donc typage fort oblige, tu peux pas t'enregistrer n'importe ou.

En tout cas, merci pour ton lien, je vais lire ça avec attention.