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


141

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?

Réponses:


151

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>

12
J'ai eu toutes sortes de problèmes similaires à celui-ci avec différentes versions de chargement / non chargement. Une autre astuce que vous pouvez essayer consiste à supprimer manuellement tous les fichiers de votre dossier C: /WINDOWS/Microsoft.NET/Framework/v4.0.30319/Temporary ASP.NET Files / root / 90233b18 / 10d54998. Parfois, lors de la recompilation de sites Web, ASP.Net ne nettoie pas ce dossier en raison de certains verrous de fichiers et ces dll peuvent s'accrocher à d'anciennes références. Ça vaut le coup, je sais que ça a marché pour moi dans le passé.
Chris Conway

1
Vous avez résolu un problème connexe pour moi - merci! Un formulaire hérité de mon application C # ne s'ouvrirait pas dans le concepteur car il recherchait une ancienne version d'une référence. Il s'avère qu'une autre référence avait été créée à l'origine lors du référencement de cette ancienne version de la référence du problème.
Sam Skuce

2
Si vous vous promenez dans
Junior Mayhé

1
Merci Chris! Vous avez résolu mon problème ici: stackoverflow.com/q/11490177/7850
Shaul Behr

3
Vous pouvez également consulter votre App.config ou web.config et voir si les <dependentAssembly>entrées existantes sont à l'origine du problème.
Roy Tinker

24

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>

2
Je voulais dire "sentir", ça me dérange depuis des mois maintenant :)
Michael La Voie

21

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.

entrez la description de l'image ici

J'espère que cela t'aides.


30
C'est ce que signifie voter le +1.
xr280xr

7
Mais parfois, le simple vote positif ne résume pas suffisamment à quel point la réponse vous rend heureux et soulagé - après avoir passé des heures et des heures à essayer de résoudre un problème stupide qui ne devrait même pas être un problème, et vous essayez de le rechercher d'une manière différente. , trouvez une réponse différente de celle que vous aviez essayée auparavant, et boum! ça fonctionne maintenant! Après tout cela, parfois, le simple fait d'appuyer sur le bouton de vote positif ne rend pas justice à ce sentiment écrasant de, mec, vous m'avez vraiment sorti de celui-ci.
Michael Plautz

7

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
Le nettoyage du répertoire C: \ Users \ USERNAME \ .nuget \ packages \ était ce qui me manquait. Merci beaucoup!
Herdo

pour nettoyer l'ancienne version de nuget, dans un ordinateur Windows, ckuck Démarrer et rechercher "exécuter"> copier et coller "% userprofile% \. nuget \ packages" - cela ouvrira le dossier des versions de
nuget

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


2
J'ai également découvert ce cauchemar - même si vous supprimez l'assemblage du GAC, il laisse de mauvaises références de version dans "C: \ Windows \ Microsoft.NET \ Framework \ v2.0.50727 \ CONFIG \ machine.config"
Evalds Urtans

3

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.


2

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.


Aucun autre projet en solution et aucune autre DLL référencée faisant référence à telerik. Je ne fais référence qu'aux DLL MS ala System. *
Michael La Voie

2

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.


2

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


2

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.


1

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


1

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.


1

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.


1

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.


Oui - inclus une version dans le nom dans notre bibliothèque d'assemblage commune pour éviter les problèmes de dénomination dans le contrôle de code source. J'ai changé le nom et mis à jour manuellement les chemins de références / indices et tout a fonctionné.
Mathew Paxinos

0

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.


0

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


0

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.


0

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:

entrez la description de l'image ici


Vous avez posté exactement la même réponse à 2 questions différentes?
AK47

0

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.


0

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


0

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

entrez la description de l'image ici

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

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

entrez la description de l'image ici

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

entrez la description de l'image ici


0

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.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.