La définition de manifeste de l’assembly localisé ne correspond pas à la référence de l’assembly

Le chargeur .NET Assembly ne parvient pas à trouver 1.2.0.203, mais a trouvé un 1.2.0.200. Cet assemblage ne correspond pas à ce qui a été demandé et vous obtenez donc cette erreur. En termes simples, il ne peut pas trouver l’assembly qui a été référencé. Assurez-vous qu’il peut trouver le bon assemblage en le plaçant dans le GAC ou dans le chemin de l’application. Voir également http://blogs.msdn.com/junfeng/archive/2004/03/25/95826.aspx .

Vous pouvez faire certaines choses pour résoudre ce problème. Tout d’abord, utilisez la recherche de fichiers Windows pour rechercher votre assembly (.dll) sur votre disque dur. Une fois que vous avez une liste de résultats, faites View-> Choose Details … et cochez ensuite “File Version”. Cela affichera le numéro de version dans la liste des résultats, afin que vous puissiez voir d’où pourrait provenir l’ancienne version.

En outre, comme dit Lars, vérifiez votre GAC pour voir quelle version y est répertoriée. Cet article Microsoft stipule que les assemblys trouvés dans le GAC ne sont pas copiés localement lors d’une génération, vous devrez donc peut-être supprimer l’ancienne version avant de procéder à une reconstruction. (Voir ma réponse à cette question pour des notes sur la création d’un fichier de commandes pour le faire pour vous)

Si vous ne pouvez toujours pas savoir d’où vient l’ancienne version, vous pouvez utiliser l’application fuslogvw.exe fournie avec Visual Studio pour obtenir plus d’informations sur les échecs de liaison. Microsoft a des informations sur cet outil ici . Notez que vous devez activer la journalisation en définissant la HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Fusion\EnableLog registre HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Fusion\EnableLog sur 1.

J’ai juste rencontré ce problème moi-même et j’ai trouvé que le problème était différent de ce que les autres avaient rencontré.

J’ai eu deux DLL que mon projet principal faisait référence: CompanyClasses.dll et CompanyControls.dll. Je recevais une erreur d’exécution en disant:

Impossible de charger le fichier ou l’assembly ‘CompanyClasses, Version = 1.4.1.0, Culture = neutral, PublicKeyToken = 045746ba8544160c’ ou l’une de ses dépendances. La définition de manifeste de l’assembly localisé ne correspond pas à la référence de l’assembly

Le problème était que je n’avais aucun fichier CompanyClasses.dll sur mon système avec un numéro de version de 1.4.1. Aucun dans le GAC, aucun dans les dossiers de l’application … aucun. J’ai cherché mon disque dur entier. Tous les fichiers CompanyClasses.dll que j’avais étaient 1.4.2.

Le vrai problème, j’ai trouvé, était que CompanyControls.dll référencé la version 1.4.1 de CompanyClasses.dll. Je viens de recomstackr CompanyControls.dll (après l’avoir fait référence à CompanyClasses.dll 1.4.2) et cette erreur a disparu pour moi.

La suite redirige toute version d’assembly vers la version 3.1.0.0. Nous avons un script qui mettra toujours à jour cette référence dans App.config afin de ne plus jamais avoir à traiter ce problème.

Par reflection, vous pouvez obtenir l’assembly publicKeyToken et générer ce bloc à partir du fichier .dll lui-même.

Notez que sans atsortingbut d’espace de noms XML (xmlns), cela ne fonctionnera pas.

Si vous utilisez Visual Studio, essayez “clean solution” puis reconstruisez votre projet.

Si vous ne vous souciez pas de la version et que vous souhaitez simplement que votre application s’exécute, cliquez avec le bouton droit sur la référence et définissez la version spécifique sur false. Les autres solutions ne fonctionneraient pas pour moi.

J’ai juste couru à travers ce problème et le problème était que j’avais une ancienne copie du fichier .dll dans le répertoire de débogage de mon application. Vous voudrez peut-être aussi vérifier là-bas (au lieu du GAC) pour voir si vous le voyez.

J’ai ajouté un package NuGet, seulement pour réaliser qu’une partie noire de mon application faisait référence à une ancienne version de la bibliothèque.

J’ai supprimé le package et référencé le fichier DLL statique de l’ancienne version, mais le fichier web.config n’a jamais été mis à jour depuis:

à quoi il aurait dû revenir lorsque j’ai désinstallé le paquet:

Dans mon cas, il s’agissait d’une ancienne version de la DLL dans le répertoire C: \ WINDOWS \ Microsoft.NET \ Framework \ ~ \ Temporary ASP.NET Files \. Vous pouvez supprimer ou remplacer l’ancienne version ou supprimer et append la référence à la DLL dans votre projet. Fondamentalement, de toute façon créera un nouveau pointeur vers les fichiers ASP.NET temporaires.

Dans mon cas, cette erreur s’est produite lors de l’exécution d’une application ASP.NET. La solution était de:

1. Supprimer les dossiers obj et bin dans le dossier du projet

Le nettoyage ne fonctionnait pas, la reconstruction ne fonctionnait pas, toutes les références étaient correctes, mais ce n’était pas écrit dans une des bibliothèques. Après avoir supprimé ces répertoires, tout fonctionnait parfaitement.

Pour nous, le problème a été causé par autre chose. Le fichier de licence des composants DevExpress comprenait deux lignes, une pour une ancienne version des composants qui n’était pas installée sur cet ordinateur particulier. La suppression de l’ancienne version du fichier de licence a résolu le problème.

La partie ennuyeuse est que le message d’erreur ne donnait aucune indication sur la référence à l’origine des problèmes.

Cette même erreur est renvoyée si vous essayez de lier en retard en utilisant la reflection, si l’assembly auquel vous vous êtes lié reçoit un nom fort ou si son jeton de clé publique a été modifié. L’erreur est la même, même si aucun assemblage n’a été trouvé avec le jeton de clé publique spécifié.

Vous devez append le jeton de clé publique correct (vous pouvez l’obtenir en utilisant sn -T sur la DLL) pour résoudre l’erreur. J’espère que cela t’aides.

La mienne était une situation très similaire à celle du poste de Nathan Bedford mais avec une légère torsion. Mon projet a également fait référence à la DLL modifiée de deux manières. 1) Directement et 2) Indirectement en référençant un composant (bibliothèque de classes) lui-même ayant une référence au dll modifié. Maintenant, mon projet Visual Studio pour le composant (2) a fait référence à la version correcte de la DLL modifiée. Cependant, le numéro de version du composant lui-même n’a PAS été modifié. Par conséquent, l’installation de la nouvelle version du projet n’a pas réussi à remplacer ce composant sur l’ordinateur client.

Résultat final: La référence directe (1) et la référence indirecte (2) indiquaient différentes versions de la DLL modifiée sur la machine client. Sur ma machine de développement, ça marchait bien.

Résolution: supprimer l’application; Supprimer tous les DLLS du dossier d’application; Réinstallez.Simple comme ça dans mon cas.

Je laisserai quelqu’un profiter de ma stupidité. J’ai des dépendances à une application complètement séparée (appelons cette App1). Les DLL de cette App1 sont extraites dans ma nouvelle application (App2). Chaque fois que je fais des mises à jour dans APP1, je dois créer de nouvelles dll et les copier dans App2. Bien. . J’en ai eu marre de copier et de coller entre 2 versions différentes d’App1, alors j’ai simplement ajouté un préfixe ‘NEW_’ aux dll.

Bien. . . J’imagine que le processus de génération parsing le dossier / bin et lorsqu’il correspond à quelque chose de manière incorrecte, il affiche le même message d’erreur que celui indiqué ci-dessus. J’ai supprimé mes versions “new_” et il a construit juste dandy.

Mon problème consistait à copier le code source sur une nouvelle machine sans déplacer aucun des assemblys référencés.

Rien de ce que j’ai fait n’a corrigé l’erreur, alors j’ai hâte de supprimer le répertoire BIN. Reconstruit mon code source, et cela a fonctionné à partir de là.

Je voudrais juste append que je créais un projet ASP.NET MVC 4 de base et ajoutais DotNetOpenAuth.AspNet via NuGet. Cela a provoqué la même erreur après avoir référencé un fichier DLL incompatible pour Microsoft.Web.WebPages.OAuth.

Pour y remédier, j’ai effectué un Update-Package et nettoyé la solution pour une reconstruction complète.

Cela a fonctionné pour moi et est un peu paresseux, mais le temps, c’est de l’argent 😛

J’ai eu cette erreur lors de la création du service de génération de Team Foundation Server. Il s’est avéré que plusieurs projets de ma solution utilisaient différentes versions de la même bibliothèque ajoutée avec NuGet. J’ai supprimé toutes les anciennes versions avec NuGet et ajouté la nouvelle comme référence pour tous.

Team Foundation Server place tous les fichiers DLL dans un seul répertoire et il ne peut bien sûr y avoir qu’un seul fichier DLL d’un nom donné.

Je viens de trouver une autre raison pour laquelle obtenir cette erreur. J’ai nettoyé mon GAC de toutes les versions d’une bibliothèque spécifique et créé mon projet en me référant à une version spécifique déployée avec l’exécutable. Lorsque je lance le projet, j’ai cette exception en recherchant une version plus récente de la bibliothèque.

La raison était la politique de l’éditeur . Lorsque j’ai désinstallé les versions de la bibliothèque de GAC, j’ai oublié de désinstaller également les assemblys de règles de l’éditeur. Au lieu d’utiliser mon assembly déployé localement, l’assembleur a trouvé une stratégie d’éditeur dans GAC lui demandant de rechercher une nouvelle version.

Pour moi, la configuration de la couverture de code dans le fichier “Local.testtesttings” “provoquait” le problème. J’ai oublié de mettre à jour les fichiers qui y étaient référencés.

Mon app.config contient un

pour npgsql. D’une manière ou d’une autre sur la machine de l’utilisateur, mon app.exe.config a disparu. Je ne suis pas sûr que ce soit un utilisateur idiot, un problème d’installation ou encore un anti-virus démenti. Le remplacement du fichier a résolu le problème.

nettoyer et reconstruire la solution peut ne pas remplacer toutes les DLL du répertoire de sortie.

ce que je suggère est d’essayer de renommer le dossier de “bin” en “oldbin” ou “obj” en “oldobj”

puis essayez à nouveau de construire votre silution.

Si vous utilisez des fichiers dll tiers, copiez-les dans le dossier “bin” ou “obj” nouvellement créé après une compilation réussie.

J’espère que cela fonctionnera pour vous.

La suppression manuelle de l’ancien assembly de l’emplacement du dossier, puis l’ajout de la référence aux nouveaux assemblys peut aider.

J’ai eu la même erreur … Dans mon cas, il a été résolu comme suit:

• Au début, lorsque l’application était installée, les utilisateurs avaient utilisé Microsoft Enterprise Library 4.1 dans l’application.
• Au cours de la semaine précédente, ma machine a été formatée et après cela, lorsque j’ai créé cette application, cela m’a donné une erreur, à savoir que l’assembly Enterprise Library est manquant.
• Ensuite, j’ai installé Microsoft Enterprise Library 5.0 que j’ai trouvé sur Google en tant que première entrée de recherche.
• Ensuite, lorsque j’ai construit l’application, il m’a donné l’erreur ci-dessus, c’est-à-dire que la définition du manifeste de l’assembly situé ne correspond pas à la référence de l’assembly.
• Après une bonne partie du travail de recherche et d’parsing, j’ai constaté que l’application faisait référence à 4.1.0.0 et que la DLL dans le dossier bin était de la version 5.0.0.0.
• J’ai ensuite installé Microsoft Enterprise Library 4.1.
• Suppression de la référence précédente (5.0) et ajout de la référence 4.0.
• Construit l’application & voila … ça a marché.

Voici ma méthode pour résoudre ce problème.

1. À partir du message d’exception, obtenez le nom de la bibliothèque “problem” et le numéro de version “attendu”.

2. Trouvez toutes les copies de ce fichier .dll dans votre solution, cliquez dessus avec le bouton droit de la souris et vérifiez la version du fichier .dll.

Ok, donc dans cet exemple, mon .dll est définitivement 2.0.5022.0 (le numéro de version d’Exception est donc faux).

3. Recherchez le numéro de version indiqué dans le message Exception dans tous les fichiers .csproj de votre solution. Remplacez ce numéro de version par le nombre réel de la DLL.

Donc, dans cet exemple, je remplacerais ceci …

… avec ça…

Travail terminé !

La suppression du contenu du dossier bin de votre projet et la reconstruction de la solution ont résolu mon problème.

Dans mon cas, le problème était entre la chaise et le clavier 🙂

 Could not load file or assembly 'DotNetOpenAuth.Core, Version=4.0.0.0, Culture=neutral, PublicKeyToken=2780ccd10d57b246' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040) 

Deux assemblages différents ou plus souhaitaient utiliser une version différente de la bibliothèque DotNetOpenAuth, ce qui ne poserait pas de problème. De plus, sur mon ordinateur local, un fichier web.config a été automatiquement mis à jour par NuGet:

Puis j’ai réalisé que j’avais oublié de copier / déployer le nouveau web.config sur le serveur de production. Donc, si vous avez un moyen manuel de déployer web.config, vérifiez qu’il est mis à jour. Si vous avez complètement différent web.config pour le serveur de production, vous devez fusionner ces sections dependAssembly en synchronisation après avoir utilisé NuGet.

J’ai reçu ce message d’erreur suite à la référence à un assemblage portant le même nom que l’assemblage que je construisais.

Cela compilé mais il a remplacé l’assembly référencé avec l’assembly de projets en cours – provoquant ainsi l’erreur.

Pour y remédier, j’ai modifié le nom du projet et les propriétés de l’assemblage en cliquant avec le bouton droit sur le projet et en sélectionnant “Propriétés”.

Dans votre fichier AssemblyVersion dans AssemblyInfo.cs, utilisez un numéro de version fixe au lieu de spécifier *. Le * changera le numéro de version sur chaque compilation. C’était le problème pour cette exception dans mon cas.

J’ai rencontré ce problème en utilisant un référentiel de packages interne. J’avais ajouté le package principal au référentiel interne, mais pas les dépendances du package. Veillez également à append toutes les dépendances, dépendances des dépendances, etc. récursives à votre référentiel interne.

J’ai eu le même problème aujourd’hui qui m’a empêché d’effectuer Add-Migration après avoir apporté des modifications à Entity Framework.

J’avais deux projets dans ma solution, appelons-les “Client” et “Données” – un projet de bibliothèque de classes qui contenait mes modèles EF et leur contexte. Le client a référencé le projet de données.

J’avais signé les deux projets, puis apporté des modifications à un modèle EF. Après avoir enlevé la signature, j’ai pu append les migrations et j’ai pu signer à nouveau le projet.

J’espère que cela peut être utile pour quelqu’un, les épargnant de frustration prolongée ..