Discussion :

[samball]

Salut à tous,

Cela fait pas mal de temps maintenant que je cherche à résoudre le problème suivant de la "bonne manière":

J'ai une application principale qui charge des plugins suivant le mode suivant:

• récupération des répertoires contenant les plugins
• chargement des dll en utilisant "Assembly.ReflectionOnlyLoadFrom" (pour voir si la dll implémente bien l'interface de plugin)
• chargement du plugin en utilisant "Assembly.LoadFrom"

Tout se passe bien tant que mes plugins n'ont pas de dépendances. Sur les machines des développeurs, cela ne pose pas de problème car la plupart des dépendances sont dans la GAC ou dans le PATH.
Or sur les machines utilisateur, certaines dépendances ne sont pas trouvées.

Voila un apperçu de l'architecture de l'application:

• ./application.exe
• ./plugins/pluginA/pluginA.dll
• ./plugins/pluginB/dependanceA.dll
• ./plugins/pluginB/pluginB.dll
• ./plugins/pluginB/dependanceB.dll
• ./plugins/pluginC/pluginC.dll
• ./plugins/pluginC/dependanceC.dll

J'ai déjà testé de nombreuses solutions:

• ajouter les répertoires de plugins dans la variable d'env PATH
• utiliser la callback "AppDomain.AssemblyResolve"
• rajouter les répertoires en utilisant "AppDomain.AppendPrivatePath" (mais qui est deprecated)
• utiliser différentes combinaisons de "Assembly.Load(string)", "Assembly.Load(AssemblyName)", "Assembly.LoadFile" et "Assembly.LoadFrom"

Je n'ai pourtant réussi à faire marcher aucune des ces techniques. La problématique semblant tellement simple ("chargement de plugins avec dépendances"), suis-je en train de passer à côté de quelque chose? Y-a-t il une subtilité que je n'ai pas saisi? Bref, toute aide est la bienvenue!

Bonne journée à tous,

Merci.

[theMonz31]

tu pourrais eventuellement faire le truc suivant (mais cela me semble bizarre que ca ne marche pas chez toi)

C'est d'avoir toutes les dépendances dans le repertoire qui convient

Sinon, tu peux aussi faire un test sur les dépendances et les charger, mais cela me parait un peu fumeux comme idée

[samball]

Merci pour ta réponse.

J'ai déjà pensé faire la solution que tu propose, à savoir mettre toutes les dlls et tous les plugins dans le répertoire racine, mais cela ne correspond pas aux specs initiales du projet. De plus il faut que chaque plugin puisse être standalone (d'où l'idée d'un répertoire par plugin qui contient sa dll et ses dépendances).

[theMonz31]

ok, je vois

Peut-etre que tu peux alors changer le repertoire courant de ton application au moment du chargement des différentes DLL pour l'affecter à la valeur du repertoire de la DLL chargée

[samball]

Ah ah, ça aussi j'ai déjà essayé sans succès.

Mais en fait, j'ai pris le problème par un autre côté, et j'ai crée un petit prototype qui charge des plugins référençant des DLLs externes (dans le même répertoire), qu'elles soient managées ou non.

En déployant ce prototype sur les machines clients, je me suis aperçu que la stratégie de chargement de plugins que j'ai décrit dans le premier post marche comme elle devrait.

Donc le problème ne vient pas de là J'ai l'impression que c'est plus un problème de dépendances propres à SQLCE (c'est cette DLL qui fait échouer le démarrage).

Merci quand même