21 votes

Références du projet DLL version hell

Nous avons des problèmes pour que Visual Studio récupère la dernière version d'une DLL d'un de nos projets.

Nous avons plusieurs projets de bibliothèques de classes (par exemple BusinessLogic, ReportData) et un certain nombre de services Web, chacun ayant une référence à une DLL de connectivité que nous avons écrite (cette référence à la DLL de connectivité est le problème).

Nous pointons toujours les références à la DLL dans le dossier bin/debug, (qui est l'endroit où nous construisons toujours pour un projet donné) et toutes les références DLL personnalisées ont CopyLocal = True et SpecificVersion = False.

ReportData fait référence à la logique d'entreprise (qui fait également référence à la connectivité - je ne vois pas pourquoi cela poserait un problème, mais j'ai pensé qu'il fallait le mentionner).

Ce qui est bizarre, c'est que lorsque vous cliquez sur "Ajouter une référence" et que vous naviguez jusqu'à Connectivity/bin/debug - vous passez la souris sur le fichier DLL, la version correcte (la dernière) est affichée (la version et la version du fichier sont toujours incrémentées ensemble), mais lorsque vous cliquez sur ok, un numéro de version antérieur est affiché. Même lorsque je regarde dans le dossier de débogage du projet en cours (où la copie locale mettrait la DLL après la compilation), le numéro de la dernière version s'affiche. - Nulle part je ne peux trouver la version précédente de la DLL en dehors de Visual Studio, mais dans les références de ce projet il a l'ancienne version - même si le chemin est correct.

Je ne sais pas d'où il peut tirer les anciennes versions. Ou même pourquoi il veut celle-là.

C'est probablement le problème de rectitude le plus frustrant que j'aie jamais rencontré.

Quelqu'un sait-il comment s'assurer que la dernière version est transmise (de préférence automatiquement ou à la compilation) ?

EDIT :

Bien que ce ne soit pas exactement le scénario auquel j'ai affaire, je lisais este et quelque part il est mentionné que le CLR ignore les numéros de révision. C'est compréhensible (même si cela n'a jamais été un problème auparavant - nous en sommes à la révision 39), j'ai donc pensé mettre à jour le numéro de build, mais cela n'a toujours pas fonctionné. Dans une vaine tentative, j'ai pensé mettre à jour le numéro de version mineure et voir si cela faisait une différence.

Je ne dis pas que c'est la solution car je dois d'abord vérifier un certain nombre de choses, mais à première vue, cela semble avoir résolu mon problème...

Modification ultérieure : Dans d'autres bibliothèques de classes, cela semble avoir résolu le problème, mais dans une application Windows de test, une version précédente est toujours présente :(

Si j'incrémente à nouveau le numéro de la version mineure, le même problème revient et je me retrouve avec une version erronée.

Autre modification - J'ai créé un tout nouveau projet, ajouté une référence et j'ai toujours le même problème. Cela suggère que le problème est limité au projet auquel je fais référence. J'aimerais bien savoir pourquoi !

Quelqu'un a-t-il déjà eu ce problème et sait-il comment le contourner ?

AIDE !

0voto

davidtj Points 31

L'une des raisons possibles est le PATH de référence. S'il y a une référence à l'ancien dossier de dll, VS l'utilisera comme référence principale, même si vous avez ajouté la référence de la nouvelle dll.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X