Discussion :

[Pasquall]

Bonjour à tous

Alors, bien que je ne soit pas un nouvel inscrit, je ne crois pas avoir déjà posté ici je vais donc faire une courte présentation.
Je suis développeur depuis 5 ans en SSII et cela fait maintenant 3 ans que je travail sur un projet perso entièrement développé en C# (Framework 2.0), j'ai donc un peu de bouteille.

Depuis peu, j'ai un problème qui me fait tourner en rond malgré les heures de recherche sur google et sur tout les sites/forum de développement que je fréquente régulièrement.

Je vais donc vous exposer ce problème.
Je souhaite découper intelligemment une application que je projette de faire en différentes librairies de classe, et j'aimerai organiser ces différentes librairies dans divers dossiers en fonction de ce à quoi elles servent. (plugins, services de bases, couche de communication BDD/reseaux, etc)
Jusqu'ici, référencer une classlib dans un exe ou dans un autre classlib ne pose pas de problème en soit, mais ce qui me gène, c'est que systématiquement, lorsqu'on ajoute une référence vers une classlib (dans VS.net 2005), les librairies mises en références sont systématiquement copiée dans le dossier de production de la librairie utilisatrice.
Un bon schéma vaut mieux qu'une longue explication:
- dossier principal de l'application
---- dossier de librairies communes
-------lib1.dll
-------lib2.dll
---- dossier de librairies référençant les librairies communes
-------libAutre1.dll
-------libAutre2.dll
-------lib1.dll (copiée automatiquement lors de la génération, et indésirable à cette endroit)
-------lib2.dll (copiée automatiquement lors de la génération, et indésirable à cette endroit)

Je ne sais absolument si il est possible de référencer et d'utiliser des librairies qui ne se trouvent pas dans le dossier ou on les utilise (sans faire un système de plugin/addIn avec une interface générique en late binding), mais si il y a un moyen...j'aimerai bien le connaitre.

D'avance merci à ceux qui pourront m'apporter des éléments de réponse.

[olibara]

Salut

Je pense que tu confond "dossier de production" et dossiers des projets constituant une solution

Dans une solution découpée en projet ayant chacun un dossier il me semble naturel que les dll référencée soient recopiées dans les dossier de chaque projet, une dll n'a pas a connaitre l'emplacement physique des methodes référencées

Mais en production rien ne t'empeche de recentraliser tout dans un meme dossier

[Pasquall]

Salut

Merci pour ta réponse.
Alors non je ne confond pas le dossier de production et le dossier projet.
Justement, quand on ajouter des références vers des classlib d'une même solution, les librairies ne sont pas copiée dans le dossier du projet "utilisateur".

Mon problème est que j'aurai plusieurs types de plugins ayant des interfaces différentes, mais utilisant des librairies de classes communes, et que je souhaiterai justement que tout ne soit pas au même niveau.

Je sais que System.Reflection permet de détecter "quoi" possède quelle interface, ce qui me permettrai de filtrer quelle DLL est de quel type et donc de charger correctement chaque type de plugin, mais si je pouvais éviter d'avoir 12000 DLL au même niveau, je préfèrerai (c'est un souhait, pas une exigence)

En continuant mes recherches j'ai trouvé un premier élément de réponse avec AppDomain dans un article très intéressant (http://vincentlaine.developpez.com/t...domain/csharp/).

Mais bon, cela ne répond pas a mon problèmes de références de classlib par d'autres classlib.

Je continue mes recherches.