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

Question

J'essaie d'exécuter des tests unitaires dans une application C# Windows Forms (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=neutre, PublicKeyToken=764d581291d764f7' ou l'une de ses dépendances. La définition du manifeste de l'assemblage localisé ne correspond pas à la référence de l'assemblage. (Exception de HRESULT : 0x80131040)**.

at x.Foo.FooGO()

at x.Foo.Foo2(String groupName_) in Foo.cs:ligne 123

at x.Foo.UnitTests.FooTests.TestFoo() in FooTests.cs:ligne 98**

System.IO.FileLoadException : Impossible de charger le fichier ou l'assemblage 'Utility, Version=1.2.0.203, Culture=neutre, PublicKeyToken=764d581291d764f7' ou l'une de ses dépendances. La définition du manifeste de l'assemblage localisé ne correspond pas à la référence de l'assemblage. (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).

Avez-vous des suggestions sur la façon de déterminer ce qui essaie de faire référence à cette ancienne version de la DLL ?

De plus, je ne pense pas avoir cet ancien montage sur mon disque dur. Existe-t-il un outil permettant de rechercher cette ancienne version de l'assemblage ?

Answer 1

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

Answer 2

Vous pouvez faire plusieurs choses pour résoudre ce problème. Tout d'abord, utilisez la recherche de fichiers de Windows pour rechercher votre assemblage (.dll) sur votre disque dur. Une fois que vous avez une liste de résultats, faites View->Choose Details... et cochez "File Version". Le numéro de version s'affichera dans la liste des résultats, ce qui vous permettra de savoir d'où provient l'ancienne version.

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

Si vous ne parvenez toujours pas à déterminer l'origine de 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 l'option HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Fusion\EnableLog clé de registre à 1.

Answer 3

Je viens de rencontrer ce problème moi-même, et j'ai découvert que le problème était différent de celui rencontré par les autres.

J'avais deux DLLs que mon projet principal référençait : CompanyClasses.dll et CompanyControls.dll. Je recevais une erreur d'exécution disant :

Impossible de charger le fichier ou l'assemblage CompanyClasses, Version=1.4.1.0, Culture=neutre, PublicKeyToken=045746ba8544160c' or l'une de ses dépendances. La définition du manifeste de l'assemblage de l'assemblage localisé ne ne correspond pas à la référence de l'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. Aucun dans le GAC, aucun dans les dossiers d'applications... aucun nulle part. J'ai cherché dans tout mon disque dur. Tous les fichiers CompanyClasses.dll que j'avais étaient des versions 1.4.2.

J'ai découvert que le vrai problème était que CompanyControls.dll faisait référence à la version 1.4.1 de CompanyClasses.dll. J'ai simplement recompilé CompanyControls.dll (après l'avoir fait référencer CompanyClasses.dll 1.4.2) et cette erreur a disparu pour moi.

Answer 4

Ce qui suit redirige toute version de l'assemblage vers la version 3.1.0.0, nous avons un script qui mettra toujours à jour cette référence dans l'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 un attribut d'espace de nom xml (xmlns), cela ne fonctionnera pas.

Answer 5

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