Question La définition de manifeste de l'assembly localisé ne correspond pas à la référence d'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'assemblage 'Utility, Version = 1.2.0.200, Culture = neutral, PublicKeyToken = 764d581291d764f7' 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) **

à x.Foo.FooGO ()

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

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

System.IO.FileLoadException: Impossible de charger le fichier ou l'assemblage 'Utility, Version = 1.2.0.203, Culture = neutral, PublicKeyToken = 764d581291d764f7' 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)

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

Des suggestions sur la façon dont je comprends ce qui essaie de faire référence à cette ancienne version de ce fichier DLL?

D'ailleurs, je ne pense pas que j'ai même cette vieille assemblée sur mon disque dur. Existe-t-il un outil pour rechercher cet ancien assemblage versionné?


591
2017-10-18 13:16


origine


Réponses:


Le chargeur d'assembly .NET est incapable de trouver 1.2.0.203, mais a trouvé un 1.2.0.200. Cet assembly ne correspond pas à ce qui a été demandé et donc vous obtenez 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. Regarde aussi http://blogs.msdn.com/junfeng/archive/2004/03/25/95826.aspx.


379
2017-10-18 13:39



Vous pouvez faire un certain nombre de choses pour résoudre ce problème. Tout d'abord, utilisez la recherche de fichiers Windows pour rechercher votre assembly sur votre disque dur (.dll). Une fois que vous avez une liste de résultats, faites View-> Choose Details ... puis cochez la case "Version du fichier". Cela affichera le numéro de version dans la liste des résultats, ainsi vous pouvez voir d'où l'ancienne version pourrait provenir.

Aussi, comme l'a dit Lars, vérifiez votre GAC pour voir quelle version est listée ici. Cet article de Microsoft indique que les assemblages trouvés dans le GAC ne sont pas copiés localement au cours d'une construction, vous devrez donc 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 batch pour le faire pour vous)

Si vous ne parvenez toujours pas à comprendre d'où provient 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 devrez activer la journalisation en définissant le HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Fusion\EnableLog clé de registre à 1.


85
2017-10-20 21:31



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

J'avais 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'assemblage   'CompanyClasses, Version = 1.4.1.0,   Culture = neutre,   PublicKeyToken = 045746ba8544160c 'ou   une de ses dépendances. Le situé   la définition manifeste de l'assembly   ne correspond pas à la référence d'assemblage

Le problème était, je n'ai eu 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 d'application ... aucun n'importe où. 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é 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 est partie pour moi.


52
2017-11-17 19:15



La section suivante redirige toute version d'assembly vers la version 3.1.0.0. Nous avons un script qui mettra toujours cette référence à jour dans App.config afin que nous n'ayons plus jamais à faire face à 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 un attribut d'espace de noms XML (xmlns) cela ne fonctionnera pas.


39
2017-11-02 00:34



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


32
2017-07-13 03:27



Si vous ne vous souciez pas de la version et que vous souhaitez simplement que votre application s'exécute, faites un clic droit sur la référence et définissez 'version spécifique' sur false. Les autres solutions ne fonctionneraient pas pour moi. enter image description here


31
2018-06-28 17:21



J'ai juste couru à travers ce problème et le problème était que j'avais une vieille copie du fichier .dll dans mon répertoire de débogage de l'application. Vous pouvez également vérifier ici (au lieu du GAC) pour voir si vous le voyez.


20
2017-09-03 00:00



J'ai ajouté un paquet de NuGet, seulement pour réaliser une partie de boîte noire de mon application 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 à partir de:

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

16
2018-03-05 16:22



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, de toute façon va créer un nouveau pointeur vers les fichiers temporaires ASP.NET.


13
2017-09-15 17:07



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

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

Propre ne fonctionnait pas, reconstruire ne fonctionnait pas, toutes les références étaient bien, mais il n'écrivait pas l'une des bibliothèques. Après avoir supprimé ces répertoires, tout a parfaitement fonctionné.


12
2017-10-09 18:34



Pour nous, le problème a été causé par 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. 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 à quelle référence causait les problèmes.


8
2017-11-23 11:09