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

Nous rencontrons un problème très similaire avec le WPFToolkit. Nous venons de passer à la version de février 2010 (en utilisant le msi du 5 mars). "Ajouter des références" montre les bons fichiers dans le bon emplacement, mais liste les anciens numéros de version. Cependant, les fichiers physiques ont les numéros de version corrects. J'ai désinstallé, supprimé manuellement toutes les références WPFToolkit du registre, etc. en vain. Il doit mettre ces choses en cache quelque part, mais nous n'avons pas encore été en mesure de le découvrir. Je perds des heures sur ce problème.

Answer 2

Activez FusionLog et après l'échec du chargement de la DLL, ouvrez le fichier portant le nom de la DLL dans le dossier C:\FusionLog\Default\devenv.exe. Cela montrera le chemin à partir duquel la DLL a été réellement chargée.

Dans mon cas, une ancienne version était mystérieusement apparue dans la base de données de la Commission européenne.

C:\Program Fichiers \Microsoft Visual Studio 10 \Common7\IDE !

Pour empêcher que cela ne se reproduise, j'ai ajouté une règle de sécurité "Deny Write" à Everyone sur Common7. \IDE.

Answer 3

J'ai eu un problème similaire à ce qui est décrit ici, sauf que ma solution au problème avait à voir avec la façon dont je compilais le code. Il y a une différence entre build, clean et Rebuild. Dans mon cas, j'utilisais simplement un Build entre mes modifications et la dll de la solution dépendante n'était pas reportée avec toutes les modifications apportées à l'autre solution où la référence était définie. J'ai résolu le problème en utilisant Rebuild qui nettoie, compile et lie tous les fichiers sources, qu'ils aient été modifiés ou non. Ensuite, la dll de la première solution a été mise à jour et copiée automatiquement dans la deuxième solution où la référence a été définie et le problème a été résolu. Merci, j'espère que cela vous aidera.

Answer 4

Symptômes similaires - le problème se situait dans "Referene paths" dans Project Properties, Reference.

Description complète et solution ici : Assemblages référencés automatiquement remplacés par Visual Studio visual-studio/22810867#22810867

Answer 5

Regardez ces choses :

1. si la dll problématique est référencée à la fois par l'application web hôte et par celle qui est référencée. Par exemple, disons que votre application web utilise abc.dll (problématique) et une autre dll xyz.dll (c'est-à-dire un projet de classe qui référence également abc.dll).

Dans ce cas, supposons que vous ayez mis à jour abc.dll de la version 1 à la version 2 et que vous l'ayez référencé dans votre application Web. Mais pendant le processus de construction, la version 2 de abc.dll va revenir à la version 1, car xyz.dll utilise la version 1 et l'application Web écrase la version 2 de abc.dll en abc.dll version 1 pendant la mise à jour automatique de xyz.dll.

Solution : placez la version mise à jour de la version 2 de abc.dll dans le dossier de classe de xyz.dll, également.

J'espère que les détails ci-dessus vous aideront, bonne chance