Discussion :

[PeD012]

Bonsoir,


Avant de résoudre mon problème, j’ai déjà une difficulté dans la terminologie.

Y a t il une différence ? Quelle est la différence entre :
un add-in, un plug-in, une dll.

Quelles sont les définitions strictes ( pas littéraires ) de ce termes ?

Usage différent ? Niveau de complexité différent ? Technique différente ?

Quelqu’un peut il m’expliquer ou me renvoyer vers un tutoriel afin de trouver la solution la plus appropriée.

Merci


Pierre

[DonQuiche]

Bonjour.

Si je devais définir plug-in : un composant qui ajoute des fonctionnalités.
Un add-in : un terme plus générique qui peut désigner un thème, un plug-in, etc.

Après, ils peuvent être réalisés de diverses façons. En général, en dotnet, pour un plug-in il s'agit d'une dll dans laquelle un objet expose une interface spécifique (par exemple une interface IPlugIn avec une propriété Commands ou, si l'on veut inverser le contrôle, une méthode Hook acceptant un argument IApplication et chargée de modifier l'argument). Au lancement l'application scanne les dll à la recherche de classes implémentant l'interface attendue. Bien entendu, le plug-in comme l'appli s'appuient toutes deux d'une biblio commune dans laquelle sont définies les interfaces.

[tomlev]

Je ne pense pas qu'il y ait une différence clairement définie entre add-in et plug-in ; pour moi les deux termes sont interchangeables. C'est quelque chose qui s'intègre dans une application hôte pour lui ajouter des fonctionnalités, sans que l'application ait besoin de connaitre ce plugin à l'avance.

Une DLL, c'est beaucoup plus général : c'est simplement un fichier binaire qui contient du code, comme un exe sauf que ce n'est pas directement exécutable. Les plugins/addins sont généralement sous forme de DLL, mais une DLL n'est pas forcément un plugin. Par exemple toutes les librairies de classes pour .NET sont sous forme d'une DLL.

[PeD012]

Merci pour les deux réponses.

Mais sans faire trop le difficile, désolé, je n'ai pas vraiment de réponse à ma question.

Je vois de "pauvres" exemples ( dans le sens "rares" ) pour créer une DLL et l'appeler. Cela ne me semble pas tout simple. Je vis d'ailleurs un exemple tellement simple par rapport à un autre très, très, trop? compliqué pour moi. Où est la vérité?

Je ne vois pas quelque chose de précis sur les plugins.
Quant aux addin ( ou addon ? ) cela semble être hors de propos pour mon problème.

Mon problème qui est : par exemple ne pas pouvoir faire de imports de Oracle dans l'application principale, ni tous les selects nécessaires, car quand une machine n'a pas Oracle, si je fournis un exe avec ce code, cela se plante. ( vrai aussi pour DB2 ).

Je devrais donc externaliser cela - sans doute - dans une DLL, qui ne serait chargée que volontairement et en connaissance de cause par l'utilisateur.

Donc même si dans l'exe le code Oracle n'est pas réellement utilisé, cela donne des erreurs.

Voilà ce que j'ai à résoudre.

Bonsoir aux vaillants développeurs :--))

Encore merci.

Pierre

[DonQuiche]

Bonsoir, voici la mise en oeuvre à suivre :

1. Créer une dll "common" qui sera utilisée par l'application et le plug-in. Elle contiendra une interface "IOracleProvider" et éventuellement toute autre interface que le plug-in devra fournir ou recevoir.

2. Ecrire le code de chargement du plugin : l'application parcourt tous les types publics de la dll (Assembly.Load, Assembly.GetTypes) jusqu'à en trouver un qui implémente IOracleProvider (typeof(IOracleProvider).IsAssignableFrom), l'instancie (Activator.CreateInstance) et le stocke dans une classe statique Plugins contenant une propriété statique OracleProvider du type IOracleProvider.

3. Modifier le code de l'appli pour que toutes les parties utilisant Oracle fassent appel à Plugins.OracleProvider en vérifiant si celui-ci est nul ou non.


Variante possible : Remplacer IOracleProvider par un IDbProvider que tous les services d'accès aux données implémenteront.


PS : Curieux quand même ce bug avec le code oracle même s'il n'est pas appelé, ça voudrait le coup de se pencher dessus.

[PeD012]

Merci. Je vais relire plusieurs fois ( sorry ma vraie compétence est IBM Mainframe ) et vais mettre en oeuvre.


Pour l'erreur à l'exécution, je pourrais collecter les informations d'une manière plus précise et les poster ici .... si cela intéresse quelqu'un.

Maintenant je retiens l'idée aussi de me passer des Imports Oracle et DB2 pour les remplacer par un Idbprovider ( ODBC ? ou OleDb ?? ).

Bonsoir

Je prends un peu de temps pour mettre cela en execution.
Salut

Pierre

[DonQuiche]

Pour l'erreur à l'exécution, je pourrais collecter les informations d'une manière plus précise et les poster ici .... si cela intéresse quelqu'un.

C'est surtout qu'on doit pouvoir résoudre le problème d'une façon plus simple.
Il n'est pas normal qu'un code provoque un crash sans être exécuté, par sa seule présence.

Maintenant je retiens l'idée aussi de me passer des Imports Oracle et DB2 pour les remplacer par un Idbprovider ( ODBC ? ou OleDb ?? ).

Si on peut se satisfaire d'une communication indirecte avec la DB, autant s'appuyer sur ADO.Net (éventuellement via un ORM reposant sur ADO comme Entity ou NHibernate) : cette couche fera appel au driver ODBC ou OLE DB correspondant pour fournir une abstraction sur laquelle le dév peut s'appuyer pour travailler à peu près indifféremment avec n'importe quel SGBD.