[.NET2] HÉBERGEUR DE PLUGINS AVEC CHARGEMENT ET DÉCHARGEMENT DE PLUGINS
cs_Warny
Messages postés473Date d'inscriptionmercredi 7 août 2002StatutMembreDernière intervention10 juin 2015
-
25 juil. 2007 à 09:06
BaFM
Messages postés64Date d'inscriptionmercredi 24 juillet 2002StatutMembreDernière intervention26 novembre 2009
-
14 avril 2008 à 20:03
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
BaFM
Messages postés64Date d'inscriptionmercredi 24 juillet 2002StatutMembreDernière intervention26 novembre 2009 14 avril 2008 à 20:03
Bonjour,
Pour ceux qui suivent la source, une nouvelle version plus puissante, plus clair, et plus commentée a été publie il y a quelques jours. Suite à une étrangeté, la mise à jour est marquée deux fois, mais c'est rien, c'est là même. Tout le texte de la source a été mis à jour aussi, il faut donc relire.
MyGoddess
medelidrissi
Messages postés180Date d'inscriptionjeudi 21 août 2003StatutMembreDernière intervention26 novembre 20072 9 oct. 2007 à 20:44
Félicitations, très bonne source.
Dommage que ce n'est pas commenté. Autrement, je pense que le plus important est dit dans la description :d.
Bonne Programmation.
BaFM
Messages postés64Date d'inscriptionmercredi 24 juillet 2002StatutMembreDernière intervention26 novembre 2009 25 juil. 2007 à 15:31
Tu n'a pas compris. Essaie avec ta version de charger une autre version d'une assembly, normalement, ca plantera. Car il verras que tu as déjà chargé l'assembly ou parce qu'il te diras qu'il peut pas la charger. Avec la solution que je propose, tu peux avoir de chargé en même temps, plusieurs versions d'un même assembly. De plus ce n'est pas juste les objets ou les informations de type que je décharge, c'est toutes les informations de type. Si tu garde le pointeur vers un plugin, puis que tu décharge le plugin et donc toute l'assembly et le domaine d'application qui va avec, et que après tu essaie d'appeler un méthode sur l'objet, il te dirat tout simplement : "Impossible d'effectuer l'appel, le composant distant n'est plus disponible." Enfin un truc du style.
Après je part d'un interface et pas d'une classe d'une part parce que c'est moins contraignant à écrire et le concepteur gère le fait de te demander d'implémenter directement au niveau de l'éditeur, pas besoin de taper override, et d'autre part pour permettre d'hériter d'une classe dérivant de MarshalByRefObject et pas obligatoirement de MarshalByRefObject. Puisque ma source peu être utilisée tel qu'elle pour définir n'importe quel type de plugin personnalisé, puisque ca ne contient que les informations nécessaire à l'hébergeur, c'est à la personne qui va l'utiliser d'implémenter son interface de plugin en implémentant celui de l'hébergeur.
Il est vrai que je n'ai pas expliquer le principe sur lequel ca se basait et sur quel niveau exactement se fesait le déchargement, qui est je le reprécise au niveau de code et des meta donnees en eux-mêmes et pas seulement des données.
J'espère avoir réussi a te faire comprendre la légère différence de fonctionnalité.
cs_Warny
Messages postés473Date d'inscriptionmercredi 7 août 2002StatutMembreDernière intervention10 juin 2015 25 juil. 2007 à 15:15
Ma source permet de précharger dans l'application cliente des DLL et les classes qu'elle contiennent en fonction d'une interface ou d'une classe de base puis d'instancier les objets à la demande. Mais je peux aussi enlever des classes de l'instancieur sans problème (c'est une collection). Si j'ai bien compris ce que fait ta source, c'est qu'elle précharge les classes pour pouvoir les utiliser dans un programme externe, non ? Sinon, c'est mal expliqué.
Mon principe surtout d'utiliser une classe paramétrable qui permet d'utiliser n'importe quelle classe ou interface de référence. Le principe peut certainement être réappliqué à ton cas.
BaFM
Messages postés64Date d'inscriptionmercredi 24 juillet 2002StatutMembreDernière intervention26 novembre 2009 25 juil. 2007 à 14:07
Sympa de faire la pub pour ta source Warny...
Enfin, là on a deux besoins différents (je fesais du même style que ce que tu as fait avant, mais avec des interfaces), ta source serait plutôt utile dans le cadre d'une application client qui peux être fermée/relancée si on veux virer des plugins. La mienne serait plutôt pour une application serveur ou une application client qui est assez lourde à charger. Ce qui signifie que l'on peux mettre un peu plus de contraintes à nos objets.
cs_Warny
Messages postés473Date d'inscriptionmercredi 7 août 2002StatutMembreDernière intervention10 juin 2015 25 juil. 2007 à 09:06
14 avril 2008 à 20:03
Pour ceux qui suivent la source, une nouvelle version plus puissante, plus clair, et plus commentée a été publie il y a quelques jours. Suite à une étrangeté, la mise à jour est marquée deux fois, mais c'est rien, c'est là même. Tout le texte de la source a été mis à jour aussi, il faut donc relire.
MyGoddess
9 oct. 2007 à 20:44
Dommage que ce n'est pas commenté. Autrement, je pense que le plus important est dit dans la description :d.
Bonne Programmation.
25 juil. 2007 à 15:31
Après je part d'un interface et pas d'une classe d'une part parce que c'est moins contraignant à écrire et le concepteur gère le fait de te demander d'implémenter directement au niveau de l'éditeur, pas besoin de taper override, et d'autre part pour permettre d'hériter d'une classe dérivant de MarshalByRefObject et pas obligatoirement de MarshalByRefObject. Puisque ma source peu être utilisée tel qu'elle pour définir n'importe quel type de plugin personnalisé, puisque ca ne contient que les informations nécessaire à l'hébergeur, c'est à la personne qui va l'utiliser d'implémenter son interface de plugin en implémentant celui de l'hébergeur.
Il est vrai que je n'ai pas expliquer le principe sur lequel ca se basait et sur quel niveau exactement se fesait le déchargement, qui est je le reprécise au niveau de code et des meta donnees en eux-mêmes et pas seulement des données.
J'espère avoir réussi a te faire comprendre la légère différence de fonctionnalité.
25 juil. 2007 à 15:15
Mon principe surtout d'utiliser une classe paramétrable qui permet d'utiliser n'importe quelle classe ou interface de référence. Le principe peut certainement être réappliqué à ton cas.
25 juil. 2007 à 14:07
Enfin, là on a deux besoins différents (je fesais du même style que ce que tu as fait avant, mais avec des interfaces), ta source serait plutôt utile dans le cadre d'une application client qui peux être fermée/relancée si on veux virer des plugins. La mienne serait plutôt pour une application serveur ou une application client qui est assez lourde à charger. Ce qui signifie que l'on peux mettre un peu plus de contraintes à nos objets.
25 juil. 2007 à 09:06
http://www.csharpfr.com/codes/CREATION-DYNAMIQUE-OBJETS_41547.aspx