[WPF] Génération des dlls

Bonjour,

Je suis confronté à un petit problème que je n'arrive pas à résoudre :

J'ai une application qui a en référence une dll de contrôle utilisateur (que l'on va appeler dll A) que j'ai créé.
Cette dll A fait référence à des dlls d'une autre societé (que l'on va appeler dlls B). Donc à coté de ma dll A, lors de la compilation, j'ai dlls B se rajoute à côté car elles sont necessaire. Ce qui est tout à fait normal.
Le problème c'est que mon application utilise les dlls B mais dans une autre version et ces dlls sont également présente à coté de mon .exe.

Là est le problème, j'ai mon exe avec ses dlls plus la dll A mais la dll A a rapporter ses dlls B. Du coup je ne peut pas avoir plusieurs fois les mêmes dll dans le même dossier.

Dans un soucis d'organisation, nous aimerons pouvoir avoir cette architecture :
/ programme.exe
/ dlls B de mon exe
/ UnDossier / dll A
/ UnDossier / dlls B de dll A


Le problème est que je ne sais pas comment faire pour que mon programme aille chercher la dll A autre par qu'a côté de lui.


C'est compliqué donc j'espère que vous m'aurez compris.


Merci d'avance.

c'est du grand n'importe quoi de vouloir utiliser 2 versions différentes d'une même dll en même temps
je crois qu'il y a un moyen de charger une dll par code, mais je ne pense pas que ca suffira, car un exe se retrouve dans un domaine d'exécution avec les dll qu'il utilise, donc je ne suis pas sûr que ca ne va pas s'emmeler les pinceaux d'avoir 2x la même dll dans le domaine

Désolé mais c'est mon entreprise qui me le demande, et ce n'est pas du grand n'importe quoi, je t'explique :
Ce projet va être étalé sur 5-10 ans et des contrôles utilisateurs comme la dll A vont être rajouté peut à peut, on ne pourra pas refaire chaque logiciel (oui car un contrôle utilisateur A est en fait, un petit logiciel) pour qu'ils utilisent la même version, là ce serait du grand n'importe quoi.

J'ai découvert une autre solution : de ne faire qu'une seule dll en sorti de projet (donc qui contient ses dlls) j'ai découvert ILMerge, j'espère que cela pourra marcher mais ça a l'air compliqué à mettre en place...

j'ai failli évoquer ilmerge, mais je ne l'ai pas fait pensant que ca ne marcherait pas, car si l'ancienne et la nouvelle dll ont des classes en commun la clr risque de ne pas savoir laquelle appeler et dans ce cas on a en général un message "nom ambigu"
je me retrouve parfois avec des problèmes de référence, avec 2 même dll en référence, l'une compilée en debug et l'autre en release et ca plante ...

par contre rien ne t'empeche de faire une dll pour tes anciens programme et un autre pour les nouveaux

et ce n'est pas parce qu'un patron pond ca en accord avec une démarche de produit que c'est forcément modélisable et possible

Bonjour,
Je ne connais pas vos contraintes mais je mettrais simplement les DLL dans le GAC.
Un kit d'installation pour gérer tout ça et pas de soucis à avoir.
il faut gérer ses versions de DLL correctement et tout devrait fonctionner.
Cdlt.

dans le GAC avec un numéro de version différente ca doit etre possible oui
quand on ajoute une dll du framework en référence on peut choisir la version qu'on veut utiliser

Ok merci à vous deux, je vais me renseigner sur ça.

Je vous tiens au courant.

Citation:

---

Envoyé par Floco

Ce projet va être étalé sur 5-10 ans et des contrôles utilisateurs comme la dll A vont être rajouté peut à peut, on ne pourra pas refaire chaque logiciel (oui car un contrôle utilisateur A est en fait, un petit logiciel) pour qu'ils utilisent la même version, là ce serait du grand n'importe quoi.

---

Il n'y a pas forcément besoin de "refaire chaque logiciel"... il peut suffire de le recompiler en référençant la nouvelle version des DLL B (en supposant que celles-ci respectent la compatibilité ascendante).

Ou même, encore plus simple : dans les propriétés des références aux DLL B, tu mets "Specific Version" à false. Comme ça, ça fonctionnera avec n'importe quelle version des DLL, sans recompilation (avec la même contrainte de compatibilité que ci-dessus)

Le problème est que ces dlls B ne respectent pas beaucoup la compatibilité ascendante (les contrôles Telerik tu connais? :mouarf:) donc je vais explorer la solution du GAC pour l'instant.
Mais si vous avez des idées un peut plus simple, je suis preneur.

Merci

Citation:

---

Envoyé par Floco

Le problème est que ces dlls B ne respectent pas beaucoup la compatibilité ascendante (les contrôles Telerik tu connais? :mouarf:)

---

Je connaissais de nom, mais maintenant j'ai plus envie de mieux connaître :aie:

lol

Remarque, j'avais eu une expérience un peu similaire avec les contrôles DevExpress... le numéro de version était inclus dans le nom de l'assembly, donc obligé de modifier toutes les références à chaque nouvelle version :mur:

Citation:

---

Envoyé par tomlev

Remarque, j'avais eu une expérience un peu similaire avec les contrôles DevExpress... le numéro de version était inclus dans le nom de l'assembly, donc obligé de modifier toutes les références à chaque nouvelle version :mur:

---

Ouép mais en même temps, tu peux faire cohabiter plusieurs versions en parallèle. C'est ce qu'on fait au boulot sur les composants Winform mais je le conseille pas :aie:

Citation:

---

Envoyé par PitMaverick78

Ouép mais en même temps, tu peux faire cohabiter plusieurs versions en parallèle.

---

C'est vrai que pour le problème de Floco ça aurait plutôt été un avantage...

Merci pour vos réponses :)

Dans un premier temps, je vais essayer en suffixant les dlls par leur numéro de version et du coup changer les références.
Si ça ne marche pas, je serais obliger d'utiliser le GAC (ce que l'on m'a fortement déconseillé au boulot).

En tout cas, merci à vous !

J'ai un gros soucis 8O
Je ne peut pas renommer les dlls telerik car elles sont faites de sorte que si on la renomme, elle ne marche plus (je parle bien de son nom physique sur le disque dur).
Du coup, je ne peut plus les suffixer de la version, et de cette façon, je ne peut plus utiliser le GAC car il aurait fallu aussi renommer les dlls.

Si vous avez d'autres solutions, je suis preneur.

Du coup on va surement faire appel à une entreprise spécialisée pour nous conseiller ou alors recoder tout nos logiciels pour les passer à une même version pour tous et là, ça va pas être joli joli :aie:

Regarde si tu peux t'en sortir avec les assembly bindings...
http://msdn.microsoft.com/en-us/library/twy1dw1e.aspx

Par exemple, en supposant que tu aies les assemblies 1.3 dans le répertoire de l'exécutable, et les assemblies 1.4 dans le répertoire des plugins, tu devrais pouvoir faire un truc dans ce style :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

<configuration> <runtime> <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1"> <dependentAssembly> <assemblyIdentity name="Telerik" publicKeyToken="32ab4ba45e0a69a1" <codeBase version="1.4.0.0" href="plugins/Telerik.dll"/> </dependentAssembly> </assemblyBinding> </runtime> </configuration>

---

Je précise que c'est un peu théorique, je sais pas si ça marche vraiment comme ça... mais c'est une piste à explorer

Merci, j'essaye cette solution de suite !