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

https://stackoverflow.com/questions/215026

03-07-2019
|

Question

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

System.IO.FileLoadException: impossible de charger le fichier ou l'assembly 'Utilitaire, Version = 1.2.0.200, Culture = neutre, 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 ()

at x.Foo.Foo2 (String groupName_) dans Foo.cs: line 123

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

System.IO.FileLoadException: impossible de charger le fichier ou l'assembly 'Utilitaire, Version = 1.2.0.203, Culture = neutre, 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 ancien).

Avez-vous des suggestions pour savoir ce qui essaie de référencer cette ancienne version de ce fichier DLL?

En outre, 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é?

La solution

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 .

Autres conseils

Vous pouvez faire plusieurs choses pour résoudre ce problème. Commencez par utiliser 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 View - & Gt; choisissez Details ... puis vérifiez & Quot Version du fichier & Quot ;. Cela affichera le numéro de version dans la liste des résultats afin que vous puissiez voir d'où vient l'ancienne version.

Par ailleurs, comme l'a dit Lars, vérifiez dans votre GAC quelle version est répertoriée ici. Cet article de Microsoft indique que les assemblys trouvés dans le GAC ne sont pas copiés localement lors de la construction, vous devrez peut-être supprimer l'ancienne version avant de tout reconstruire. (Voir ma réponse à cette question pour des notes sur la création d'un fichier de commandes à faire. ceci pour vous)

Si vous ne savez toujours pas 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 dispose d’informations sur cet outil ici . Notez que vous devrez activer la journalisation en définissant la HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Fusion\EnableLog clé de registre sur 1.

Je viens de rencontrer ce problème moi-même et j'ai constaté qu'il s'agissait d'un problème différent de celui rencontré par les autres.

Mon projet principal faisait référence à deux DLL: 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 = neutre, PublicKeyToken = 045746ba8544160c 'ou une de ses dépendances. Le situé la définition du manifeste de l'assemblée ne ne correspond pas à la référence d'assemblage

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. Aucune dans le GAC, aucune dans les dossiers d'applications ... aucune nulle part. J'ai cherché 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.

Les éléments suivants redirigent toute version d'assembly vers la version 3.1.0.0. Nous avons un script qui mettra toujours à jour cette référence dans le fichier 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 & "Nettoyer la solution &"; 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 voulez simplement que votre application soit exécutée, cliquez avec le bouton droit de la souris sur la référence et définissez 'version spécifique' sur false ... Cela a fonctionné pour moi. entrer la description de l'image ici

Je viens de rencontrer 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 l'application. Vous voudrez peut-être aussi vérifier ici (au lieu du GAC) pour voir si vous le voyez.

J'ai ajouté un package NuGet uniquement pour réaliser qu'une partie de mon application contenant une boîte noire faisait référence à une version plus ancienne 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 package:

<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 consistait à:

Supprimez les obj et bin dossiers du dossier de projet

Nettoyer n'a pas fonctionné, la reconstruction n'a pas fonctionné, toutes les références étaient bonnes, mais il ne s'agissait pas de l'écriture d'une des bibliothèques. Après la suppression de ces répertoires, tout fonctionnait parfaitement.

Dans mon cas, il s’agissait d’une ancienne version de la DLL située dans le répertoire C: \ WINDOWS \ Microsoft.NET \ Framework \ ~ \ Temporary ASP.NET Files \. Vous pouvez supprimer ou remplacer l'ancienne version ou supprimer et rajouter la référence à la DLL de votre projet. Dans les deux cas, un nouveau pointeur sera créé sur les fichiers ASP.NET temporaires.

Je vais épater 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

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.

Ce qui est gênant, c’est que le message d’erreur n’indiquait pas quelle référence était à l’origine des problèmes.

Cette erreur est exactement la même si vous essayez de lier tardivement à l'aide d'une réflexion, si l'assembly auquel vous vous associez obtient un nom fort ou si son jeton de clé publique est 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 ajouter le bon jeton de clé publique (vous pouvez l'obtenir à l'aide de sn -T sur la dll) pour résoudre l'erreur. J'espère que cela vous aidera.

La mienne était dans une situation très semblable à celle de Nathan Bedford, mais avec une légère tournure. 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 avait lui-même une référence à la dll modifiée. Maintenant, mon projet Visual studio pour le composant (2) a référencé la version correcte de la DLL modifiée. Cependant, le numéro de version du composant lui-même n'a PAS été changé. En conséquence, l’installation de la nouvelle version du projet n’a pas réussi à remplacer ce composant sur la machine cliente.

Résultat final: Les références directe (1) et 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: supprimer l'application. Supprimer toutes les DLL du dossier de l'application; Réinstallez. Simple comme cela dans mon cas.

Je laisserai quelqu'un profiter de ma stupidité au cisaillement. J'ai quelques dépendances à une application complètement séparée (appelons cette 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 avais marre de copier-coller entre 2 versions différentes d'App1, j'ai donc simplement ajouté un préfixe 'NEW_' à la dll.

Bien. . . J'imagine que le processus de construction analyse le dossier / bin et que, s'il ne correspond pas correctement, il affiche le même message d'erreur que celui indiqué ci-dessus. J'ai supprimé mon & Quot; nouveau _ & Quot; versions et construit juste dandy.

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

Rien de ce que j'ai fait ne corrige l'erreur, alors, dans la précipitation, j'ai supprimé le répertoire BIN. Reconstruit mon code source, et cela a fonctionné à partir de là.

J'aimerais simplement ajouter que je créais un projet ASP.NET MVC 4 de base et que j'avais 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 résoudre ce problème, j’ai procédé à une Update-Package opération et nettoyé la solution pour une reconstruction complète.

Cela a fonctionné pour moi et c'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 est apparu que ma solution comportait plusieurs projets 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 seul répertoire. Il ne peut exister qu'un seul fichier DLL portant un nom donné à 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 suis pas sûr que ce soit un utilisateur idiot, un problème d'installation ou un anti-virus totalement excité. 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 lancé le projet, j'ai eu cette exception en cherchant une version plus récente de la bibliothèque.

La raison en était la stratégie de l'éditeur . Lorsque j'ai désinstallé les versions de la bibliothèque à partir de GAC, j'ai oublié de désinstaller également les assemblys de stratégies d'éditeur. Ainsi, au lieu d'utiliser mon assembly déployé localement, le chargeur d'assemblages a trouvé une stratégie d'éditeur dans GAC qui lui demandait de rechercher une version plus récente.

Pour moi, la configuration de la couverture de code dans le & "Local.testtesttings &"; fichier " causé " le problème. J'ai oublié de mettre à jour les fichiers référencés ici.

La 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 suggérerai est d'essayer de renommer le dossier de & "bin &"; à " oldbin " ou " obj " à " oldobj "

puis essayez à nouveau de construire votre silution.

si vous utilisez des dll tierces, il vous faudra les copier dans & "bin &"; ou " obj " dossier après la construction réussie.

espérons que cela fonctionnera pour vous.

La suppression manuelle de l'ancien assemblage à partir de l'emplacement du dossier, puis l'ajout de la référence à de nouveaux assemblys peuvent aider.

J'ai la même erreur ... Dans mon cas, le problème a été résolu comme suit:

Au début, lorsque l'application a été installée, les personnes ici avaient utilisé Microsoft Enterprise Library 4.1 dans l'application.
La semaine précédente, ma machine a été formatée & amp; Après cela, aujourd’hui, lorsque j’ai construit cette application, une erreur s’est produite lorsqu’il manque un assemblage de bibliothèque d’entreprise.
Ensuite, j'ai installé Microsoft Enterprise Library 5.0, que j'ai obtenue sur Google en tant que première entrée de recherche.
Puis, lorsque j'ai construit l'application, il m'a renvoyé l'erreur ci-dessus, à savoir que la définition du manifeste de l'assembly localisé ne correspond pas à la référence de l'assembly.
Après beaucoup de recherches, & amp; analyse, j'ai trouvé que l'application faisait référence 4.1.0.0 & amp; la DLL dans le dossier bin était de la version 5.0.0.0
J'ai alors installé Microsoft Enterprise Library 4.1.
Suppression de la référence précédente (5.0) & amp; a ajouté la référence 4.0.
Construit l'application & amp; voila ... ça a marché.

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

À partir du message d'exception, obtenez le nom du & "problème &"; bibliothèque et le " attendu " numéro de version.

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

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

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 actuel 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 ceci ...

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

Travail terminé!

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 ou plusieurs assemblys différents 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 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>

Ensuite, 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 web.config pour le serveur de production, vous devez fusionner cette section dependAssembly de manière synchrone après avoir utilisé NuGet.

Si vous rencontrez une erreur telle que & "; 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 > Dans l'onglet Gérer les packages et la mise à jour de NuGet, la première chose à faire est d'essayer d'installer une autre version du package après avoir vérifié les versions de page NuGet Gallery et exécution de la commande suivante depuis la console de Package Manager:

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 paquet en question et qu'elle a été posée il y a bien longtemps, c'est générique, toujours pertinent et j'espère que cela aidera quelqu'un.

J'ai reçu ce message d'erreur en raison de la référence d'un ensemble portant le même nom que celui que je construisais.

Ceci a été compilé mais il a écrasé l'assembly référencé avec l'assembly de projets actuel, ce qui a provoqué l'erreur.

Pour résoudre ce problème, j'ai modifié le nom du projet et les propriétés de l'assemblage disponibles en cliquant avec le bouton droit de la souris sur le projet et en choisissant "Propriétés".

Dans votre fichier AssemblyVersion in 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 de cette exception dans mon cas.

Licencié sous: CC-BY-SA avec attribution

Non affilié à StackOverflow