.Net picking mauvaise version d'assemblage référencée

Je viens de copier un projet existant sur une toute nouvelle machine pour commencer à développer dessus et j'ai rencontré un problème avec la version de l'un de mes assemblys référencés (une DLL telerik en l'occurrence).

Le projet faisait à l'origine référence à une version plus ancienne de l'assembly (appelons-la v1.0.0.0). Ma nouvelle machine a la dernière version de l'assemblage installée, donc j'ai pensé l'avoir mise à jour (appelons la nouvelle version v2.0.0.0).

Voici maintenant le problème: si je copie l'ancienne dll v1.0.0.0 dans le dossier du projet et que je l'ajoute comme référence, le site Web se lance sans problème. Si je supprime cette référence (et supprime également l'ancienne DLL de mon système) et ajoute la nouvelle version (v2.0.0.0), la page affiche l'exception suivante:

Impossible de charger le fichier ou l'assembly 'XXXXXX, Version = 1.0.0.0, Culture = neutral, PublicKeyToken = 121fae78165ba3d4' ou l'une de ses dépendances. La définition de manifeste de l'assembly localisé ne correspond pas à la référence d'assembly. (Exception de HRESULT: 0x80131040)

De toute évidence, le code recherche la version obsolète et ne peut pas la trouver. Mais pourquoi?

J'ai grepé le dossier de solution pour ce numéro de version et je n'ai pas trouvé une seule référence. J'ai vérifié deux fois le texte du fichier .csproj et j'ai trouvé que la version affiche correctement la dernière version et le HintPath montre correctement le chemin vers la nouvelle DLL. De plus, parce que je n'ai pas installé l'ancienne DLL sur le système, elle n'apparaît pas dans mon GAC (bien que v2.0.0.0 le fasse, comme prévu).

J'ai ensuite activé la visionneuse du journal de fusion pour essayer de comprendre pourquoi il recherche cette ancienne version, mais pas de chance:

Assembly Load Trace: The following information can be helpful to determine why the assembly 'XXXXXX, Version=1.0.0.0, Culture=neutral, PublicKeyToken=121fae78165ba3d4' could not be loaded.


=== Pre-bind state information ===
LOG: User = MyComp\me
LOG: DisplayName = XXXXXX, Version=1.0.0.0, Culture=neutral, PublicKeyToken=121fae78165ba3d4
 (Fully-specified)
LOG: Appbase = file:///d:/My Documents/Visual Studio 2010/Projects/CoolProj/WebApp/
LOG: Initial PrivatePath = d:\My Documents\Visual Studio 2010\Projects\CoolProj\WebApp\bin
Calling assembly : WebApp, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null.
===
LOG: This bind starts in default load context.
LOG: Using application configuration file: d:\My Documents\Visual Studio 2010\Projects\CoolProj\WebApp\web.config
LOG: Using host configuration file: 
LOG: Using machine configuration file from C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\config\machine.config.
LOG: Post-policy reference: XXXXXX, Version=1.0.0.0, Culture=neutral, PublicKeyToken=121fae78165ba3d4
LOG: Attempting download of new URL file:///C:/WINDOWS/Microsoft.NET/Framework/v4.0.30319/Temporary ASP.NET Files/root/90233b18/10d54998/XXXXXX.DLL.
LOG: Attempting download of new URL file:///C:/WINDOWS/Microsoft.NET/Framework/v4.0.30319/Temporary ASP.NET Files/root/90233b18/10d54998/XXXXXX/XXXXXX.DLL.
LOG: Attempting download of new URL file:///d:/My Documents/Visual Studio 2010/Projects/CoolProj/WebApp/bin/XXXXXX.DLL.
WRN: Comparing the assembly name resulted in the mismatch: Major Version
ERR: Failed to complete setup of assembly (hr = 0x80131040). Probing terminated.

Tout ce qu'il dit c'est qu'il commence par chercher cette ancienne assemblée. J'ai essayé de trouver une solution en ligne et j'ai vu cette question SO similaire , mais cela semble être exactement le contraire de mon problème. Le programme de cet interrogateur trouvait la mauvaise DLL au lieu de celle référencée. Alors que mon problème est que le programme recherche mystérieusement la mauvaise DLL et est incapable de la trouver lorsque la bonne se trouve localement dans le dossier bin et dans le GAC.

Pourquoi le mien cherche-t-il l'ancienne version? Où puis-je rechercher pour trouver cette mauvaise référence?

Je suppose qu'un autre assemblage que vous utilisez fait référence à l'ancienne DLL. Connaissez-vous toutes les autres références de projet utilisées et est-ce que certaines d'entre elles font référence aux dll Telerik?

Pouvez-vous mettre une redirection de liaison dans votre fichier web.config comme ceci?

<dependentAssembly>
 <assemblyIdentity name="Telerik" publicKeyToken="121fae78165ba3d4"/>
 <bindingRedirect oldVersion="1.0.0.0" newVersion="2.0.0.0"/>
</dependentAssembly>

Je suis avec Chris Conway sur celui-ci (je l'ai voté). Le problème est que vous faites référence à l'un des assemblys telerik de votre projet qui en référence un autre qui n'est pas là.

Première chose: je n'installerais AUCUN assemblage de fournisseur (ie: telerik) dans le GAC. Le contenu de Telerik est de toute façon compilé à seulement deux assemblys (telerik.web.design et telerik.web.ui). Déployez-les simplement avec l'application.

Deuxièmement, dans chacun de vos fichiers .proj (comme .csproj), il y aura un <reference include..>qui pointe vers le fichier Telerik.Web.UI. Celui-ci contient normalement un numéro de version. Assurez-vous que l'assemblage que vous avez placé dans le dossier bin correspond à cette version.

Troisièmement, assurez-vous que TOUS vos projets utilisent le dernier assemblage. Assurez-vous également qu'ils récupèrent l'assembly à partir d'un chemin local au lieu du GAC. (Je n'aime vraiment vraiment pas le GAC. Cela a causé des problèmes sans fin sur certains projets sur lesquels j'ai été). Nous avons généralement un dossier «Assemblies» que tous les projets utilisent pour les références d'assemblage externes.

Quatrièmement, Visual Studio recherche automatiquement votre gac à chaque fois qu'un projet de site Web est chargé et recible les emplacements d'assemblage s'il trouve quelque chose dans le gac. Je ne me souviens pas s'il le fait jamais pour les projets d'application Web, mais je n'ai pas eu de problème avec ceux-ci depuis longtemps. Cela peut provoquer des problèmes similaires lors du déploiement.

Cinquièmement, vous pouvez relier les numéros de version des assemblys dans le fichier web.config. Dans la runtime/assemblybindingsection, vous pouvez utiliser quelque chose comme ce qui suit qui fait avancer chaque assembly telerik déployé en 2008 et le pointe vers une version très particulière:

  <dependentAssembly>
    <assemblyIdentity name="Telerik.Web.UI" publicKeyToken="121fae78165ba3d4" />
    <bindingRedirect oldVersion="2008.0.0.0-2020.0.0.0" newVersion="2010.02.0713.35" />
  </dependentAssembly>

J'ai essayé la plupart des réponses mais je n'ai toujours pas réussi à le faire fonctionner. Cela a fonctionné pour moi:

Faites un clic droit sur la référence -> propriétés -> changez «Version spécifique» en faux.

J'espère que cela t'aides.

Essayer:

• nettoyage des fichiers de projet temporaires
• nettoyage des fichiers build et obj
• nettoyage d'anciennes versions installées sur C:\Users\USERNAME\.nuget\packages\

Cela a fonctionné pour moi.

1. Accédez à C: \ WINDOWS \ Microsoft.NET \ Framework \ v2.0.50727 \ CONFIG
2. Rechercher le fichier machine.config
3. ouvrir dans le bloc-notes
4. trouver une DLL de conflit
5. Supprimez-le et enregistrez-le.

assemblages de compilation

addassembly = dllName, Version = 1.0.0000.0000 Culture = neutre, PublicKeyToken = "QWEWQERWETERY"

compilation d'assemblages

travaille pour moi.

Ce n'est pas une réponse claire quant à la raison, mais nous avons eu ce problème, voici nos circonstances et ce qui l'a résolu:

Dev 1:

La solution contient le projet A référençant un package NuGet et un projet MVC référençant le projet A. Activation de la restauration du package NuGet, puis mise à jour du package NuGet. Vous avez une erreur d'exécution qui se plaint que la bibliothèque NuGet est introuvable - mais l'erreur est qu'elle recherche l'ancienne version non mise à jour. Solution (et c'est ridicule): définissez un point d'arrêt sur la première ligne de code dans le projet MVC qui appelle le projet A. Entrez avec F11. Résolu - n'a plus jamais eu de problème.

Dev 2:

Même solution et projets, mais le point d'arrêt magique et l'étape de la solution ne fonctionnent pas. J'ai cherché partout des redirections de version ou d'autres mauvaises références à ce package Nuget, supprimé le package et le réinstaller, essuyé bin, obj, Asp.Net Temp, rien ne l'a résolu. Enfin, renommé Projet A, a exécuté le projet MVC - corrigé. Renommé à son nom d'origine, il est resté fixe.

Je n'ai aucune explication sur les raisons pour lesquelles cela a fonctionné, mais cela nous a permis de nous sortir d'une grave embardée.

Avez-vous d'autres projets dans cette solution? (Peut-être qu'un autre projet faisait référence à une ancienne version) Habituellement, dans VS, la dépendance dll couvre tous les projets de la solution.

Mon problème était que les anciens assemblys se trouvaient dans le dossier _bin_deployableAssemblies sous l'application Web. Cela signifiait que les anciens assemblys remplaçaient les assemblys GAC lors de la construction du projet.

Au cas où cela ferait gagner 3 heures à quelqu'un d'autre ... mon cas était un peu différent. Mon code utilisait DevExpress v11.1 v11.1.4.0. J'avais tout référencé correctement dans mon code. Mais le profileur de mémoire .net a installé DevExpress v11.1 v11.1.12.0 dans le GAC. En fait, ce ne sont pas les composants auxquels j'ai fait référence, mais ceux auxquels ils ont fait référence en interne qui ont échoué. Essayez comme je pourrais, le GAC est toujours vérifié en premier. Il s'est compilé et a bien fonctionné, mais je ne pouvais pas voir le concepteur de formulaires win et la trace de la pile n'était d'aucune aide. Enfin désinstallé le profileur de mémoire .net et tout a été restauré.

J'ai eu un problème similaire et j'ai dû tout supprimer des dossiers bin et obj et reconstruire pour surmonter mon problème. J'espère que cela t'aides.

Si vous rencontrez ce problème lors du test et / ou du débogage de l'application à partir de l'environnement Visual Studio (ASP.NET Development Server), il est nécessaire de supprimer tous les fichiers temporaires du dossier du site Web de développement. Pour savoir où se trouve ce dossier, recherchez l'icône du serveur de développement ASP.NET sur l'icône de la barre d'état Windows (elle doit avoir un titre comme celui-ci: Serveur de développement ASP.NET - Port ####), cliquez avec le bouton droit sur l'icône et sélectionnez Afficher Détails; thn, le champ Chemin physique vous dira quel est le dossier temporaire, tous les éléments doivent être supprimés pour résoudre le problème. Construisez et exécutez à nouveau le site Web et le problème devrait être résolu (encore une fois, résolu pour l'environnement de développement).

J'ai eu le même problème avec différents assemblages référençant différentes versions de Newtonsoft.json. La solution qui a fonctionné pour moi exécutait update-package à partir de la console Nuget Package Manager.

Cette erreur était quelque peu trompeuse - je chargeais des DLL qui nécessitaient la spécification d'une architecture x64. Dans le .csprojfichier:

<PropertyGroup Condition="'$(Configuration)|$(Platform)' == 'Release-ABC|AnyCPU'">
    <OutputPath>bin\Release-ABC</OutputPath>
    <PlatformTarget>x64</PlatformTarget>
</PropertyGroup>

Un manquant a PlatformTargetcausé cette erreur.

Je recevais:

Impossible de charger le fichier ou l'assembly 'XXX-new-3.3.0.0' ou l'une de ses dépendances. La définition de manifeste de l'assembly localisé ne correspond pas à la référence d'assembly. (Exception de HRESULT: 0x80131040)

C'est parce que j'ai changé le nom de l'assemblage de XXX.dllen XXX-new-3.3.0.0.dll. Le retour du nom à l'original a corrigé l'erreur.

C'est presque comme si vous deviez effacer votre ordinateur pour vous débarrasser de l'ancienne DLL. J'ai déjà tout essayé ci-dessus, puis je suis allé à l'étape supplémentaire de simplement supprimer chaque instance du fichier .DLL qui était sur mon ordinateur et de supprimer toutes les références de l'application. Cependant, il compile toujours très bien et quand il s'exécute, il fait référence aux fonctions dll très bien. Je commence à me demander s'il le fait référence à partir d'un lecteur réseau quelque part.

J'ai eu le même message lors du basculement entre deux versions d'une application faisant référence à différentes versions de la même DLL. Bien que je testais dans différents dossiers, j'ai accidentellement copié la version la plus récente sur l'ancienne version.

La première chose à vérifier est donc la version de la DLL référencée dans le dossier de l'application. Au cas où.

Peut-être que cela aide ou peut-être pas. J'ai nettoyé mes versions de débogage et de publication, puis j'ai renommé le dossier OBJ. Cela m'a finalement fait peur. Les étapes précédentes consistaient essentiellement à supprimer des références de projet et à les rajouter dans les propriétés du projet.

Dans My Visual Studio 2015, je me suis assuré que la liste des chemins de référence du projet Visual Studio incriminé est vide:

C'est ce qui a fonctionné pour moi:

J'utilisais la Microsoft.IdentityModel.Clients.ActiveDirectoryversion 3.19 dans un projet de bibliothèque de classes mais je n'avais installé que la version 2.22 dans le projet d'application Web ASP.NET réel. La mise à niveau vers la version 3.19 dans le projet d'application Web m'a permis de surmonter l'erreur.

Dans mon cas, j'avais 3 projets, 1 projet principal et 2 sous-projets référencés par projet principal .. J'ai donc mis à jour le projet principal, laissant de côté le sous-projet. C'est là que se situait le conflit. Après avoir mis à jour tout mon projet, tout a très bien fonctionné.

Dans VS2017, j'ai essayé toutes les solutions ci-dessus mais rien ne fonctionne. Nous utilisons Azure devops pour la gestion des versions.

1. Depuis l'explorateur d'équipes> Explorateur de contrôle de source

2. Sélectionnez le projet qui vous rend fou depuis longtemps

3. Faites un clic droit sur la branche ou la solution> Avancé> obtenir une version spécifique

4. Ensuite, assurez-vous que vous avez coché la case d'écrasement des fichiers selon la capture d'écran

Dans mon cas, j'ai accidentellement choisi la mauvaise version du package Telerik de nuget, qui nuget a ensuite remplacé chaque package que j'ai référencé par la version incorrecte. Il a ensuite inséré une redirection de liaison vers la version incorrecte de sorte que même après avoir tout remplacé par la version correcte, il recherchait toujours la version incorrecte.