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

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

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 .

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.

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.

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.

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

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.

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.

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

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>

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

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.

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.

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.

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.

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.

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

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

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.

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.

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.

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.

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

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.

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.

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

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

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

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

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

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.

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.

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.

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