766 votes

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

Je suis en train de lancer quelques tests unitaires en C# application Windows Forms (Visual Studio 2005) et j'obtiens l'erreur suivante:

Système.IO.FileLoadException: impossible de charger le fichier ou l'assembly 'Utilitaire, Version=1.2.0.200, Culture=neutral, PublicKeyToken=764d581291d764f7' ou une de ses dépendances. L'assemblée manifeste définition ne correspond pas à la référence d'assembly. (Exception de HRESULT: 0x80131040)**

à x.Foo.FooGO()

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

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

Système.IO.FileLoadException: impossible de charger le fichier ou l'assembly 'Utilitaire, Version=1.2.0.203, Culture=neutral, PublicKeyToken=764d581291d764f7' ou une de ses dépendances. L'assemblée manifeste définition 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 à la version de l'Utilitaire de 1.2.0.203 (l'autre est vieux).

Toutes les suggestions sur la façon dont je comprendre ce qui est en train d'essayer de référence de cette ancienne version de cette DLL?

Aussi, je ne pense pas que j'ai même cette ancienne assemblée sur mon disque dur. Est-il un outil de recherche pour cette ancienne versionnées assemblée?

468voto

Lars Truijens Points 24005

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. Voir aussi http://blogs.msdn.com/junfeng/archive/2004/03/25/95826.aspx .

91voto

Seth Petry-Johnson Points 5709

Vous pouvez faire quelques choses pour résoudre ce problème. Tout d'abord, l'utilisation de fichiers de Windows search pour rechercher sur votre disque dur par votre assemblée (.dll). Une fois que vous avez une liste de résultats, voir->Choisir les Détails... et puis cochez la case "Fichier" Version. Cela permet d'afficher le numéro de version dans la liste de résultats, de sorte que vous pouvez voir où l'ancienne version peut-être en venir.

Aussi, comme le dit Lars, vérifiez votre GAC pour voir quelle version y est listé. Cet article Microsoft stipule que les assemblées trouvé dans le GAC ne sont pas copiés localement pendant une génération, de sorte que vous pouvez avoir besoin de supprimer l'ancienne version avant de faire une reconstruction de tous. (Voir ma réponse à cette question pour les notes sur la création d'un fichier de commandes pour le faire pour vous)

Si vous ne pouvez toujours pas trouver où est l'ancienne version, vous pouvez utiliser le fuslogvw.exe l'application est livré avec Visual Studio pour obtenir plus d'informations sur la liaison des échecs. Microsoft a d'informations sur cet outil ici. Notez que vous devrez activer l'enregistrement par le réglage de l' HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Fusion\EnableLog clé de registre à 1.

60voto

Nathan Bedford Points 3157

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

J'ai eu deux Dll que mon principal projet est de référencement: CompanyClasses.dll et CompanyControls.dll. J'ai été faire une erreur d'exécution en disant:

Impossible de charger le fichier ou l'assembly 'CompanyClasses, Version=1.4.1.0, Culture=neutral, PublicKeyToken=045746ba8544160c " ou l'une de ses dépendances. La situé assemblée manifeste définition n' correspond pas à la référence d'assembly

La difficulté a été, je n'ai pas de CompanyClasses.dll les fichiers sur mon système avec un numéro de version 1.4.1. Aucun dans le GAC, aucun dans l'application des dossiers...aucun n'importe où. J'ai cherché la totalité de mon disque dur. Tous les CompanyClasses.dll les fichiers 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 la CompanyClasses.dll. Je viens de recompiler CompanyControls.dll (après l'avoir référence CompanyClasses.dll 1.4.2) et cette erreur est allé loin pour moi.

53voto

Yaniv.H Points 99

Ce qui suit redirige toute version de l'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 à 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 noms xml (xmlns) cela ne fonctionnera pas.

22voto

Neal Tibrewala Points 306

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.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X