Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
modularité et dépendances dynamiques
Bonjour,
j'aimerais comprendre comment en dot NET, peut-on mettre en oeuvre la modularité et des dépendances dynamiques.
Je m'explique :
je voudrais avoir un programme A qui utilise les bibliothèques B et C. Cette bibliothèque B utilise elle aussi la bibliothèque C.
Je voudrais pouvoir faire évoluer ma bibliothèque C sans avoir forcément à recompiler la bibliothèque B pour mettre à jour la dépendance.
Est-ce possible ? Comment procéder ?
Merci à vous.
Si B utilise C et que dans C tu modifies les prototypes des membres publics qui sont utilisés dans B, tu seras obligé de modifier et recompiler B.Envoyé par behess
Si tu ne modifies dans C que des membres privés ou des algorithmes, dans ce cas là tu n'auras pas besoin de recompiler B... mais ça ce n'est pas particulier à .NET, c'est pareil partout.
Il y a toujours au moins deux solutions à un problème.
http://software-design-development.blogspot.com/
Oui tout à fait, mais si j'ajoute une classe ou une méthode... est-ce que Visual Studio va me faire #### et me dire que c'est pas la bonne version de la dll etc... ???
En fait j'ai plus l'habitude du java ou tu peux remplacer une bibliothèque par une nouvelle version sans qu'il n'y ait de problème... en théorie.
Tout dépend si tu signes tes assemblies ou pas.
Dans le cas où elles sont signées, tu risques d'avoir des problèmes en remplaçant une DLL par une autre (en fait je crois qu'il contrôle le n° de build).
Si elles ne sont pas signées, pas de problème
Il y a toujours au moins deux solutions à un problème.
http://software-design-development.blogspot.com/
En fait, si il y a un problème : si je change la librairie C sans recompiler la B, alors quand je compile le programme A qui utilise à la fois B et C, il me dit qu'il y a conflit... c'est à dire : l'assembly de la librairie B moucharde et averti qu'il est lié à une autre version de la librairie C ! Autrement dit : les assembly (dll) semblent connaitre (conserver) la version des assembly (dll) liés à la compilation ! C'est un peu ######, non ? Comment faire pour bypasser ce check ?
Edit : à vérifier si ça bloque à l'exécution... mais je ne suis pas sûr. C'est juste qu'à la compil que j'ai vu un warning (non bloquant vous me direz).
Premier test:
LibrairieC est compilé.
LibrairieB est compilé avec une référence à LibrairieC.
testMain est compilé avec une référence à LibrairieB et LibrairieC.
Ok, tout va bien.
Second test:
Librairie C est modifiée et recompilée.
testMain est recompilé et j'obtiens :
Je me dis: ok je vais supprimer les dossier obj et debug pour être sûr, je recompile, mais c'est toujours la même erreur !!! C'est quoi cette erreur à la noix ????Avertissement : impossible de copier la dépendance 'LibrairieC, Version=1.0.3348.26416, Culture=neutral' du projet 'testMain' dans le répertoire d'exécution, car elle remplacerait la référence 'LibrairieC, Version=1.0.3348.28321, Culture=neutral'.
Par contre, pour reprendre ce que je disais : à l'exécution, pas de problème si je ne recompile pas le testMain : comme tu disais ça passe avec la nouvelle version de LibrairieC : testMain et LibrairieB utilisent bien la nouvelle librairie sans remonter d'erreur.
Est-ce que tu as essayé de compiler tes assemblies sans les signer ?
Il y a toujours au moins deux solutions à un problème.
http://software-design-development.blogspot.com/
Rien n'est signé ! juste un assembly.cs avec les infos de base (pas d'infos de signature par contre).
Arglll
juste par hasard...Dans les références entre librairies, la mention specific version est bien false ?
Parce que ça sent l'inverse en fait..
Où est la mention specific ici ?
Est-ce le terme "version" ? Il suffirait de l'enlever ? Mais comment suivre les différentes version de la librairie importée ?
Ah c'est du VS2003 ?
Ah oui |-( malheureusement...
Pas étonnant alors...On va faire ça en itératif.
(Et donc, tu n'as pas le Service pack ?)
1 - Sur la solution,
Tu te mets en mode "Debug", et tu fais un clean de la solution
Tu te mets en mode "release", et tu fais un clean de la solution
2 - Tu fais une recherche dans le répertoire de la solution '*.DLL'.
Tu devrais la voir si c'est ça.
3 - Tu supprimes la(les) dll qui restent (qui peuvent etre des copies manuelles ou autre)
4 - Tu build, et tu ré-essayes.
Tu vas rire, dans ma version il n'y a même pas d'option clean... je rame à chaque fois : je quitte VS, je kill les dossier obj et bin et je rouvre VS pour regénérer...
En fait j'ai déjà fait ça sur le projet de test principal, en laissant la référence à la DLL de la librairie B et à celle de la librairie C. Mais ça ne change rien.
Mais tes références, elles sont entres projets ou entre dll ?
Ce qui est difficile à comprendre c'est qu'entre projet, tu ne devrais pas avoir cela..
Ce qui t'arrive ne peut être du qu'au principe que la dll que tu références "LibrairieC" est dans le GAC.
Donc B référence le projet C; et A référence les projet B et C ?"A qui utilise les bibliothèques B et C";
"Cette bibliothèque B utilise elle aussi la bibliothèque C."
Peux tu juste recréer les références ainsi :
Tu les supprimes
Tu t'assures que les prends les références en "add references" ou l'équivalent français
Tu t'assures de référencer les projets et pas les DLL
et avant tu peux essayer ça :
Pour être certain qu'elle n'est pas dans ton gac.C:\Program Files\Microsoft Visual Studio .NET 2003\SDK\v1.1\Bin>gacutil /U
LibrairieC
Et là tu peux builder.
presque :Donc B référence le projet C; et A référence les projet B et C ?
B référence la librairie (DLL) généré par le projet C ; et A référence les librairies B et C (pas les projets).
Non, les projets sont censés être indépendants (évolution parallèle), impossible de faire une référence par projet.Peux tu juste recréer les références ainsi :
Tu les supprimes
Tu t'assures que les prends les références en "add references" ou l'équivalent français
Tu t'assures de référencer les projets et pas les DLL
Rien dans le GAC.Pour être certain qu'elle n'est pas dans ton gac.
J'aimerais que ce soit si facileEt là tu peux builder.
Ah....C'est donc ça ton problème.
La logique de compilation fonctionne si à priori tes projets sont référencés, et dans ce cas VS fa faire une compilation 'conditionnelle'.
Là, je pense que tu as juste ton projet a qui référence la DLL au mauvais endroit, vu qu'il arrive à la copier.
Il faudrait que tu regardes das quelle path il cherche la dll LibrairieC et vérifier que c'est bien là que quand tu buildes LibrairieC il pose la dll.
Parce qu'à priori tu arrives à trouver l'ancienne version.
Donc elle est forcémment quelque part..?
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager