Références du projet DLL version hell

Question

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 !

Answer 1

Pour éviter le enfer dll Je vous recommande de créer un lib dans votre projet et placez tous les assemblages partagés dans ce dossier. Ensuite, vous ajoutez des références uniquement à partir de ce dossier. De cette façon, votre projet est autonome et vous savez exactement où il prend les références. Si vous voulez mettre à jour un assemblage avec une version plus récente, copiez-le dans le dossier lib et reconstruisez votre projet.

Assurez-vous également que vous ne mettez pas les assemblages référencés dans le GAC car ils pourraient être récupérés en premier.

Answer 2

Il y a quelques options que vous pouvez essayer.

1. Compilez le projet et voyez dans la fenêtre de sortie pour vérifier le chemin d'assemblage d'où il est référencé exactement.
2. Supprimez le dossier Obj avant de le recompiler.
3. Fermez et rouvrez le Visual Studio car VS a un comportement bizarre pour conserver le cache des références Dll.
4. Si le problème persiste, utilisez cet outil pour vérifier l'assemblage de référence d'où il provient réellement. Explorateur de processus .

Answer 3

Pour y remédier, j'ai supprimé TOUTES les références, puis je les ai rajoutées. Je ne sais pas pourquoi c'est la solution.

Il est possible que dans un projet une DLL soit incorrecte, et que ce soit cette DLL incorrecte qui ait été tirée par Visual Studio et utilisée.

Edit : Les autres fois où cette erreur s'est produite, c'est parce qu'une DDL (A) référencée dans le projet en cours est également référencée par une autre DLL (B). Le fait de ne pas reconstruire cette autre DLL (B) semble empêcher VS de référencer la bonne version de la DLL (A) dans le projet en cours et ainsi il fait passer une version plus ancienne de la DLL (A).

Answer 4

Avez-vous essayé d'ajouter la référence en tant que référence de projet ? i.e. Ajouter une référence... -> onglet Projets -> Sélectionnez votre projet

Answer 5

Nous (et, en tant que seul développeur .NET de notre équipe, j'entends par là moi) avons eu exactement le même problème. J'ai remonté la piste jusqu'à une dll référencée, qui à son tour référence à nouveau la dll souffrant de la versionitis. Il semble que, parce que je ne mettais pas à jour toutes les références qui faisaient référence à la dll souffrant de la versionitis. à leur tour a été remplacée par une version plus ancienne à un moment donné du processus de construction.

L'un des symptômes que j'ai rencontrés est que lorsque je suis dans l'éditeur de code, la nouvelle classe que j'ai ajoutée au projet référencé est colorée de manière appropriée, mais lorsque je clique sur Build, elle redevient noire et j'obtiens un message disant que la classe n'existe pas (accompagné d'un sarcastique "Ar you missing an assembly reference ?"). Cela m'a amené à penser que le problème doit se produire pendant la phase de construction.

Je vous suggère donc de construire tous les autres projets qui pointent vers cette DLL et de réajuster leurs références également.