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


751

J'essaie d'exécuter des tests unitaires dans une application Windows Forms C # (Visual Studio 2005) et j'obtiens l'erreur suivante:

System.IO.FileLoadException: impossible de charger le fichier ou l'assembly 'Utility, Version = 1.2.0.200, Culture = neutral, PublicKeyToken = 764d581291d764f7' ou l'une de ses dépendances. La définition du manifeste de l'assembly localisé ne correspond pas à la référence de l'assembly. (Exception de HRESULT: 0x80131040) **

sur x.Foo.FooGO ()

à x.Foo.Foo2 (String groupName_) dans Foo.cs: ligne 123

à x.Foo.UnitTests.FooTests.TestFoo () dans FooTests.cs: ligne 98 **

System.IO.FileLoadException: impossible de charger le fichier ou l'assembly 'Utility, Version = 1.2.0.203, Culture = neutral, PublicKeyToken = 764d581291d764f7' ou l'une de ses dépendances. La définition du manifeste de l'assembly localisé ne correspond pas à la référence de l'assembly. (Exception de HRESULT: 0x80131040)

Je regarde dans mes références, et je n'ai qu'une référence à Utility version 1.2.0.203(l'autre est ancienne).

Des suggestions sur la façon dont je découvre ce qui essaie de référencer cette ancienne version de ce fichier DLL?

D'ailleurs, je ne pense même pas avoir cet ancien assemblage sur mon disque dur. Existe-t-il un outil pour rechercher cet ancien assemblage versionné?


Dans mon cas, cela s'est produit parce que j'avais deux projets chargeant la même DLL avec des versions différentes. (j'espère que cela aide quelqu'un!)
miguelmpn

Réponses:


461

Le chargeur d'assemblage .NET:

  • est incapable de trouver le 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 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 https://docs.microsoft.com/archive/blogs/junfeng/the-located-assemblys-manifest-definition-with-name-xxx-dll-does-not-match-the-assembly-reference .


19
mais quand je regarde les références du projet, ça pointe vers 1.2.0.203 ... rien ne semble plus pointer vers 1.2.0.200
leora

128
Exactement - il recherche 1.2.0.203, mais il a trouvé 1.2.0.200. Découvrez où se trouve ce fichier et remplacez-le par la bonne version.
Jon Skeet

18
J'ai posé une question similaire ici et j'ai obtenu une solution de travail: stackoverflow.com/questions/4187907/…
Michael La Voie

13
Vérifiez la version des références, puis regardez si elle est la même dans packages.config et Web.config
zdarsky.peter

4
Ce message m'embrouille à chaque fois. Il semble être écrit à l'envers. Je m'attendrais à ce qu'il se plaigne de la version que vous avez demandé de charger, pas de la version qu'il a trouvée. Heureux que je ne sois pas le seul à se tromper!
Greg Woods

91

Vous pouvez effectuer plusieurs opérations pour résoudre ce problème. Tout d'abord, utilisez la recherche de fichiers Windows pour rechercher votre assemblage sur votre disque dur (.dll). Une fois que vous avez une liste de résultats, faites Affichage-> Choisir les détails ... puis cochez "Version du fichier". 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 l'a dit Lars, vérifiez votre GAC pour voir quelle version y est répertoriée. Cet article de Microsoft indique 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 complète. (Voir ma réponse à cette question pour des notes sur la création d'un fichier batch pour le faire pour vous)

Si vous ne parvenez toujours pas à savoir d'où provient l'ancienne version, vous pouvez utiliser l'application fuslogvw.exe livrée avec Visual Studio pour obtenir plus d'informations sur les échecs de liaison. Microsoft a des informations sur cet outil ici . Notez que vous devrez activer la journalisation en définissant la HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Fusion\EnableLogclé de Registre sur 1.


19
N'oubliez pas que la version du fichier ne fait pas partie de l'identité des assemblys. La version d'assembly est, mais ne doit pas être identique à la version de fichier!
Lars Truijens

Si vous utilisez fuslogvw pour les services, lisez blogs.msdn.com/b/junfeng/archive/2004/02/14/72912.aspx
Nick

La recherche du nom de fichier a résolu mon problème. J'avais une ancienne version de la DLL dans mon dossier ASP.Net temporaire et InstallShield l'utilisait à la place de la version à jour! Nettoyer la solution, reconstruire, redémarrer le PC n'a rien fait. Fonctionne très bien localement et explose à chaque fois qu'il est déployé.
JumpingJezza

Immédiatement après la construction, mon site fonctionne très bien, mais un peu plus tard, ce problème survient.
Shavais

J'ai plutôt édité cette réponse pour dire la version d'assembly.
Worthy7

60

Je viens de rencontrer ce problème moi-même et j'ai trouvé que le problème était quelque chose de différent de ce que les autres ont rencontré.

J'avais deux DLL auxquelles mon projet principal faisait référence: CompanyClasses.dll et CompanyControls.dll. J'obtenais une erreur d'exécution disant:

Impossible de charger le fichier ou l'assembly «CompanyClasses, version = 1.4.1.0, Culture = neutre, PublicKeyToken = 045746ba8544160c» ou l'une de ses dépendances. La définition du 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 1.4.1. Aucun dans le GAC, aucun dans les dossiers d'application ... aucun nulle part. J'ai fouillé tout mon disque dur. Tous les fichiers CompanyClasses.dll que j'avais étaient 1.4.2.

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


2
+1 Il m'est arrivé quelque chose de similaire lorsque l'une de mes DLL fait référence à une ancienne version de Caliburn Micro.
Jason Massey

moi aussi, votre expérience m'a déclenché là où je dois chercher et j'ai résolu mon problème.
Esen

Une autre option serait d'ouvrir le CompanyControlsprojet, CompanyClasses.dllSpecificVersion = false
faites un

c'est très souvent le cas sur les applications xamarin. J'ai eu un projet xamarin.forms différent du projet xamarin.droid. Je viens de voir votre message et je l'ai reconnu.
batmaci

Si CompanyClasses.dll est signé, alors SpecificVersion = falseseul ne le coupera pas. Vous en aurez besoin bindingredirect.
Denise Skidmore

53

Ce qui suit 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 que nous n'ayons plus jamais à traiter ce problème.

Grâce à la réflexion, vous pouvez obtenir l'assembly publicKeyToken et générer ce bloc à partir du fichier .dll lui-même.

<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
 <dependentAssembly>
    <assemblyIdentity name="Castle.Core" publicKeyToken="407dd0808d44fbdc" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-65535.65535.65535.65535" newVersion="3.1.0.0" />
  </dependentAssembly>
</assemblyBinding>

Notez que sans attribut d'espace de nom XML (xmlns), cela ne fonctionnera pas.


1
Cela a fonctionné pour moi. J'ai changé le 'newVersion = 3.3.3' en 'newVersion = 3.1.0'
jward01

Il vaut mieux ne pas emprunter la route de la reliure si vous pouvez l'éviter. Lorsque ce bug vient vous mordre, il mordra fort.
BanksySan

1
Mon problème était le fait que les redirections pointaient vers des assemblys inexistants.L'App.Config contenait les informations d'assemblage des derniers packages NuGet que j'avais installés. Lorsque j'ai rétrogradé ces packages plus tard, cela n'a PAS nettoyé cela. Il s'agissait d'une bibliothèque de classes standard .NET frappée par un projet de test d'unité de structure 4.7.2. Le problème du projet de test unitaire présenté lors de l'exécution ..
D-Sect

@ D-Sect a raison. Si votre contrôle de source indique que web.config a des changements (parce que vous avez joué avec vos NuGets), vous pourriez être avisé de sauvegarder ces bindingRedirects à partir de là. La rétrogradation de NuGets ne nettoiera pas les redirections de liaison
bkwdesign

45

Si vous utilisez Visual Studio, essayez «solution propre», puis reconstruisez votre projet.


14
C'est généralement la solution pour moi. Souvent, supprimez binet objfaites-le. Fondamentalement, quelque chose que j'ai utilisé pour faire référence est toujours là, essayant de satisfaire la même exigence. Par exemple, une ancienne version étant quelque chose que j'ai référencé directement et la nouvelle version étant sur NuGet.
David Betz

Vous avez rencontré ce problème pour plusieurs DLL après avoir tiré de TFS. Cette solution l'a corrigé pour moi.
Milo

3
A travaillé pour moi. Supprimé le dossier bin amd obj et résolu le problème.
user1619480

Merci, a travaillé pour moi aussi, en supprimant simplement le dossier bin.
The Cookies Dog

Pour moi, il suffisait de supprimer le bindossier. Étonnamment, j'ai essayé une solution propre et reconstruire la solution avant sans succès. Parfois un peu étrange.
Lion

36

Les autres réponses ne fonctionneraient pas pour moi. 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 "version spécifique" sur false ... Cela a fonctionné pour moi. entrez la description de l'image ici


8
Ce paramètre n'a d'effet qu'au moment de la compilation . Une fois compilé, il aura besoin de la même version d'assembly avec laquelle vous l'avez compilé. Voir stackoverflow.com/questions/24022134/…
Lars Truijens

22

Je viens de rencontrer ce problème et le problème était que j'avais une ancienne copie du fichier .dll dans mon répertoire de débogage d'application. Vous voudrez peut-être également vérifier là (au lieu du GAC) pour voir si vous le voyez.


Nous migrons simplement vers un autre serveur. Ce problème a causé la conservation des sauvegardes. A fonctionné après la suppression des copies de sauvegarde. Merci :)
Jtuck

22

Je vais souffler l'esprit de tout le monde en ce moment. . .

Supprimez toutes les <assemblyBinding>références de votre fichier .config, puis exécutez cette commande à partir de la console NuGet Package Manager:

Get-Project -All | Add-BindingRedirect

A également fonctionné pour moi. Merci
Oleh Udovytskyi

tu m'as fait gagner du temps 👌👌
Abdu Imam

4
cela ne fonctionne que lorsque le format de gestion des packages est packages.config, si vous utilisez csproj 2017 sans packages.config, cela ne fonctionne pas :(
ManiVI

1
Esprit officiellement soufflé
BGilman

c'est une belle petite astuce
hexagod

21

J'ai ajouté un package NuGet, seulement pour réaliser qu'une partie boîte 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:

<dependentAssembly>
    <assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" />
    <bindingRedirect oldVersion="0.0.0.0-4.5.0.0" newVersion="6.0.0.0" />
</dependentAssembly>

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

<dependentAssembly>
    <assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" />
    <bindingRedirect oldVersion="0.0.0.0-4.0.0.0" newVersion="4.5.0.0" />
</dependentAssembly>

J'ai vu cela où, au moins pour le module Entity Framework lorsque vous utilisez NuGet, si vous cliquez avec le bouton droit sur votre solution, accédez à Gérer les packages NuGet pour la solution, puis Packages installés> Tous, sélectionnez ce module, sélectionnez Gérer, vous pouvez généralement le désélectionnez de votre projet. Cela devrait nettoyer des choses comme celle-ci sans avoir à le faire manuellement --- en supposant que le fournisseur ait fait preuve de diligence raisonnable. Mais bonne capture comme apparemment parfois ils ne le font pas, si c'est comme ça que vous l'avez retiré.
vapcguy

20

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 objet bindans le dossier du projet

Clean ne fonctionnait pas, la reconstruction ne fonctionnait pas, toutes les références allaient bien, mais cela n'écrivait pas l'une des bibliothèques. Après avoir supprimé ces répertoires, tout a parfaitement fonctionné.


3
Merci, Levi Fuller. Cette réponse devrait être plus haut; pour ma situation c'était parfait! Pour moi, cette erreur a commencé lorsque j'ai fait une copie de sauvegarde de mon web.config et Visual Studio a continué à charger ce fichier de configuration au lieu de la configuration réelle, même après avoir supprimé la copie en double. Cela l'a résolu. Merci.
BruceHill

Fonctionne aussi pour moi. Je ne sais toujours pas pourquoi cela fonctionne :(
KangarooWest

14

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 vous pouvez supprimer et ajouter la référence à la DLL dans votre projet. Fondamentalement, l'une ou l'autre façon créera un nouveau pointeur vers les fichiers ASP.NET temporaires.


2
Cela a fonctionné pour moi lorsque j'ai fermé Visual Studio, arrêté IIS et supprimé tous les fichiers ASP.NET temporaires. Notez qu'il peut y avoir des fichiers dans le dossier Framework et Framework64 si sur une machine 64 bits, ainsi que dans les dossiers .NET 2.0 et 4.0!
Bryan B

J'ai utilisé la fonction de recherche du menu Démarrer de Windows pour trouver toutes les DLL créées par ma solution, puis j'ai supprimé tout le lot, où qu'elles se trouvent. Je pouvais le faire sans crainte car ils ne devaient être créés que lors du débogage de Visual Studio. Comme VS reconstruira ces DLL manquantes et rien en dehors de ma solution ne devrait les référencer, c'était une opération "sûre" pour moi.
Zarepheth

8

Pour nous, le problème était dû à autre chose. Le fichier de licence pour les 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 n'a donné aucune indication sur la référence à l'origine des problèmes.


2
Dans mon cas, après la mise à niveau vers la nouvelle version de DevExpress, le fichier .resx d'un formulaire contenait des références à l'ancienne version de bibliothèque désinstallée. J'ai dû ouvrir .resx en mode code et corriger la version en une nouvelle ou supprimer les entrées invalides.
Artemix

5

Cette même erreur exacte est levée si vous essayez de lier tardivement à l'aide de la réflexion, si l'assembly auquel vous liez obtient un nom fort ou si son jeton de clé publique est modifié. L'erreur est la même, même si aucun assembly n'a été trouvé avec le jeton de clé publique spécifié.

Vous devez ajouter 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.


1
Veuillez préciser - qu'est-ce que "sn -T"? Et où dois-je ajouter le jeton de clé publique?
Moritz Both

3
"sn.exe" est un outil fourni avec Visual Studio, c'est un outil de ligne de commande qui peut être exécuté à partir de l'invite de commandes Visual Studio. Exécutez simplement l'invite de commande Visual Studio (dans le menu Démarrer), accédez au dossier qui contient votre assembly et tapez «sn -T <assembly>» où <assembly> est le nom complet de la DLL. Cela obtient les informations de "jeton" de l'assembly. Une fois que vous avez cela, lorsque vous effectuez une liaison tardive avec réflexion, entrez les informations de jeton dans la chaîne d'ID d'assembly (c.-à-d. "Assembly = MyAssembly.dll, Public Key Token = <token guid>)
Guy Starbuck

2
Merci pour cette réponse. J'obtenais cette erreur lors du référencement d'une section de configuration dans mon App.ini. J'avais récemment signé l'assembly, donc le PublicKeyToken = null devait être mis à jour avec le nouveau jeton (correct).
Liam

5

La mienne était une situation très similaire au poste de Nathan Bedford mais avec une légère torsion. Mon projet a également référencé la DLL modifiée de deux manières. 1) Directement et 2) Indirectement en référençant un composant (bibliothèque de classes) qui lui-même avait une référence à la DLL modifiée. Maintenant, mon projet Visual studio pour le composant (2) faisait 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é. Et par conséquent, l'installation de la nouvelle version du projet n'a pas réussi à remplacer ce composant sur la machine cliente.

Résultat final: la référence directe (1) et la référence indirecte (2) pointaient vers différentes versions de la DLL modifiée sur la machine cliente. Sur ma machine de développement, cela a bien fonctionné.

Résolution: supprimez l'application; Supprimez toutes les DLL du dossier d'application; Réinstaller. Simple comme ça dans mon cas.


4

Je laisserai quelqu'un profiter de ma stupidité de cisaillement. J'ai quelques dépendances à une application complètement distincte (appelons cela App1). Les DLL de cette App1 sont tirées 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 assez de copier et coller entre 2 versions différentes d'App1, j'ai donc simplement ajouté un préfixe 'NEW_' aux DLL.

Bien. . . Je suppose que le processus de construction analyse le dossier / bin et quand il correspond à quelque chose de manière incorrecte, il barfs avec le même message d'erreur que noté ci-dessus. J'ai supprimé mes versions "new_" et il a construit juste dandy.


4

Mon problème était de copier le code source sur une nouvelle machine sans tirer sur aucun des assemblys référencés.

Rien de ce que j'ai fait n'a corrigé l'erreur, donc à la hâte, j'ai supprimé complètement le répertoire BIN. Reconstruit mon code source, et cela a fonctionné à partir de là.


4

Je voudrais simplement ajouter que je créais un projet ASP.NET MVC 4 de base et que j'ai ajouté DotNetOpenAuth.AspNet via NuGet. Cela a entraîné la même erreur après avoir référencé un fichier DLL incompatible pour Microsoft.Web.WebPages.OAuth.

Pour le réparer, j'ai fait Update-Packageet 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 :-P


1
Réponse similaire pour moi. Update-Package -reinstallréinstalle tous les packages NuGet dans la même version.
Jess

1
C'est bien; Merci d'avoir posté. J'ai essayé toutes ces autres excellentes suggestions, mais c'est la solution qui a fait l'affaire. Dieu merci pour les gens qui sont toujours prêts à publier une solution alternative, même quand il y en a 80 disponibles
Hambone

4

J'ai eu cette erreur lors de la construction du service de génération de Team Foundation Server. Il s'est avéré que j'avais plusieurs projets dans ma solution en utilisant différentes versions de la même bibliothèque ajoutées 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 répertoire, et il ne peut y avoir qu'un seul fichier DLL d'un certain nom à la fois.


Une autre façon consiste à cliquer sur "Gérer les packages NuGet pour la solution ..." et à mettre à jour à la fois votre projet de test et le projet en cours de test vers la même (plus récente) version.
lixonn

4

Mon app.config contient un

<bindingRedirect oldVersion="1.0.0.0" newVersion="2.0.11.0"/>

pour npgsql. D'une manière ou d'une autre sur la machine de l'utilisateur, mon app.exe.config a disparu. Je ne sais pas si c'était un utilisateur stupide, un problème d'installation ou un anti-virus déjoué. Le remplacement du fichier a résolu le problème.


3

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 construit mon projet en référence à une version spécifique déployée avec l'exécutable. Lorsque j'ai exécuté le projet, j'ai obtenu cette exception en recherchant une version plus récente de la bibliothèque.

La raison en é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 stratégie d'éditeur.Au lieu d'utiliser mon assembly déployé localement, le chargeur d'assembly a trouvé la stratégie d'éditeur dans GAC qui lui a dit de rechercher une version plus récente.


3

Pour moi, la configuration de la couverture du code dans le fichier "Local.testtesttings" "a provoqué" le problème. J'ai oublié de mettre à jour les fichiers qui y étaient référencés.


3

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


1
Eh bien, que savez-vous, vous venez de m'aider à sortir de ma misère, merci en effet
Ronny Mahlangu

2

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

ce que je vais suggérer est d'essayer de renommer le dossier de "bin" en "oldbin" ou "obj" en "oldobj"

puis essayez à nouveau de créer votre silution.

si vous utilisez des DLL de tiers, vous devrez les copier dans le dossier "bin" ou "obj" nouvellement créé après une construction réussie.

j'espère que cela fonctionnera pour vous.


1

La suppression manuelle de l'ancien assemblage de l'emplacement du dossier, puis l'ajout de la référence aux nouveaux assemblages peut être utile.


1

J'ai la même erreur ... Dans mon cas, elle a été résolue comme suit:

  • Au début, lorsque l'application a été installée, les gens ici avaient utilisé Microsoft Enterprise Library 4.1 dans l'application.
  • La semaine précédente, ma machine a été formatée et après cela, aujourd'hui, lorsque j'ai créé cette application, cela m'a donné une erreur indiquant que l'assembly de la bibliothèque d'entreprise est manquant.
  • J'ai ensuite installé Microsoft Enterprise Library 5.0 que j'ai obtenu sur Google comme première entrée de recherche.
  • Ensuite, lorsque j'ai créé l'application, cela m'a donné l'erreur ci-dessus, c'est-à-dire que la définition du manifeste de l'assembly localisé ne correspond pas à la référence de l'assembly.
  • Après beaucoup de travail de recherche et d'analyse, j'ai trouvé 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 et le tour est joué ... ça a marché.

1

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

  1. A partir du message d'exception, récupérez le nom de la bibliothèque "problème" et le numéro de version "attendu".

entrez la description de l'image ici

  1. Recherchez toutes les copies de ce fichier .dll dans votre solution, cliquez dessus avec le bouton droit et vérifiez de quelle version du fichier .dll il s'agit.

entrez la description de l'image ici

D'accord, donc dans cet exemple, mon .dll est définitivement 2.0.5022.0 (donc le numéro de version d'Exception est incorrect).

  1. Recherchez le numéro de version indiqué dans le message d'exception dans tous les fichiers .csproj de votre solution. Remplacez ce numéro de version par le numéro réel de la DLL.

Donc, dans cet exemple, je remplacerais ceci ...

<Reference Include="DocumentFormat.OpenXml, Version=2.5.5631.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL" />

... avec ça...

<Reference Include="DocumentFormat.OpenXml, Version=2.0.5022.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL" />

Travail accompli !


que faire si mes fichiers csproj n'ont pas de version référencée?
John Demetriou

1

Dans mon cas, le problème était entre le fauteuil 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 ou plusieurs assemblys différents voulaient utiliser une version différente de la bibliothèque DotNetOpenAuth, et ce ne serait pas un problème. De plus, sur mon ordinateur local, un fichier web.config a été automatiquement mis à jour par NuGet:

<dependentAssembly>
    <assemblyIdentity name="DotNetOpenAuth.AspNet" publicKeyToken="2780ccd10d57b246" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-4.3.0.0" newVersion="4.3.0.0" />
    </dependentAssembly>
    <dependentAssembly>
        <assemblyIdentity name="DotNetOpenAuth.Core" publicKeyToken="2780ccd10d57b246" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-4.3.0.0" newVersion="4.3.0.0" />
</dependentAssembly>

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 un fichier web.config complètement différent pour le serveur de production, vous devez fusionner ces sections d'assemblage dépendantes en synchronisation après avoir utilisé NuGet.


1

Si jamais vous obtenez une erreur comme « La définition du manifeste de l'assembly localisé ne correspond pas à la référence de l'assembly » et si vous avez mis à jour via Projet> Gérer les packages NuGet et l'onglet Mettre à jour dans VS , la première chose que vous pouvez faire est d'essayer d'installer une autre version de la package après avoir vérifié les versions de la page NuGet Gallery et exécuté la commande suivante à partir de la console du gestionnaire de packages:

PM> Install-Package YourPackageName -Version YourVersionNumber 
//Example
PM> Install-Package Microsoft.Extensions.FileProviders.Physical -Version 2.1.0

Bien que la réponse ne soit pas directement liée au package en question et qu'elle ait été posée il y a longtemps, elle est plutôt générique, toujours pertinente et j'espère qu'elle aidera quelqu'un.


1

Aucune solution n'a fonctionné pour moi. J'ai essayé de nettoyer la solution du projet, de supprimer le bac, de mettre à jour le package, de rétrograder le package, etc.

<dependentAssembly>
    <assemblyIdentity name="Microsoft.IdentityModel.Logging" publicKeyToken="31bf3856ad364e35" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-5.5.0.0" newVersion="5.5.0.0" />
</dependentAssembly>

à:

<dependentAssembly>
    <assemblyIdentity name="Microsoft.IdentityModel.Logging" publicKeyToken="31bf3856ad364e35" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-3.14.0.0" newVersion="5.5.0.0" />
</dependentAssembly>

Après cela, j'ai nettoyé le projet, le reconstruire et cela a fonctionné. Aucun avertissement aucun problème.


0

J'ai reçu ce message d'erreur en raison du référencement d'un assembly portant le même nom que l'assembly que je construisais.

Cela a compilé mais il a remplacé l'assembly référencé par l'assembly des projets en cours, provoquant ainsi l'erreur.

Pour le corriger, j'ai changé le nom du projet et les propriétés de l'assemblage disponibles en cliquant avec le bouton droit sur le projet et en choisissant «Propriétés».

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.