Discussion :

[behess]

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.

[Gold Bug]

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.

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.

[behess]

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.

[Gold Bug]

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... ???

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

[behess]

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).

[behess]

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 :

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'.

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 ????

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.