HRESULT: 0x80131040: La définition de manifeste de l’assembly localisé ne correspond pas à la référence de l’assembly

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

obtenir cela lors de l’exécution nunit à travers ncover. Une idée?

Il s’agit d’une incompatibilité entre les assemblys: une DLL référencée à partir d’un assembly n’a pas de signature de méthode attendue.

Nettoyez la solution, reconstruisez tout et réessayez.

Aussi, soyez prudent si cela fait référence à quelque chose qui se trouve dans le GAC; il se pourrait que quelque chose pointe quelque part vers une version incorrecte. Assurez-vous (via les propriétés de chaque référence) que la version correcte est choisie ou que la version spécifique est définie sur false.

J’ai récemment eu ce problème et j’ai couru ‘L’indore.exe’ sur la DLL en question. Il m’a montré que la DLL était compilée en x86 alors que certaines des dépendances étaient compilées en x64.

Si vous rencontrez toujours des problèmes, je vous recommande d’utiliser 2,2.

Cela se produit généralement lorsque la version de l’une des DLL de l’environnement de test ne correspond pas à l’environnement de développement.

Nettoyez et construisez votre solution et emportez toutes vos DLL dans l’environnement où l’erreur est survenue et qui devrait la corriger

Dans mon cas, pour un projet de services de repos wcf, je devais append dans le fichier web.config une section d’exécution contenant la DLL demandée, puis j’ajoutais:

      . . .  

Mes problèmes résolus en supprimant toute la partie d’exécution

             

Dans mon cas, j’ai reçu ce message pendant le débogage:

 "Error while calling service  Could not load file or assembly 'RestSharp, Version=105.2.3.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)" 

Cause

Dans mon projet, j’ai eu 2 composants internes utilisant RestSharp mais les deux composants ont une version différente de RestSharp (un avec la version 105.2.3.0 et l’autre avec la version 106.2.1.0 ).

Solution

Mettez à niveau l’un des composants pour le mettre à jour ou rétrograder l’autre. Dans mon cas, il était plus sûr pour moi de passer de 106.2.1.0 à 105.2.3.0 et de mettre à jour le composant dans le gestionnaire de paquets NuGet. Les deux composants ont donc la même version.

Reconstruire et cela a fonctionné avec des problèmes.

Dans ma situation particulière, j’ai obtenu ceci à la suite d’un CreateObject effectué dans VBScript. La cause dans mon cas était une version de l’assemblage qui résidait dans le GAC, qui était plus ancienne que celle que j’avais compilée. (en essayant de résoudre un problème antérieur, j’ai installé l’assemblage dans le GAC).

Donc, si vous travaillez avec des classes visibles COM, assurez-vous de supprimer les anciennes versions de votre assembly du GAC avant d’enregistrer votre nouvel assembly avec RegASM.

J’ai rencontré des problèmes similaires lors de l’access aux fichiers de projet depuis différents ordinateurs via un dossier partagé. Dans mon cas, clean + reabuild n’a pas aidé. Doit supprimer les dossiers bin et objects du répertoire de sortie.

Dans mon cas, c’était à cause de WebGrease. Je l’ai mis à jour vers la dernière version (en utilisant NuGet) mais il était en conflit avec les dépendances. J’ai ajouté manuellement le code ci-dessous dans web.config et cela a fonctionné comme un charme.

     

Veuillez noter que ma solution ne fonctionnera que si l’erreur est liée à WebGrease. Le code d’erreur restra le même. En outre, vous devez modifier la version dans oldVersion et newVersion en conséquence.

J’ai rencontré ce problème dans un projet Web API.

Le projet Api utilisait un paquet nuget d’une bibliothèque avec la version 3. Et l’un des assemblys référencés dit que X utilisait une version plus ancienne du même paquet nuget avec la version 2.

Chaque fois qu’un assemblage référencé est construit ou que tout autre projet faisant référence à X est reconstruit, les assemblys du projet api sont mis à jour avec la version inférieure. Et a obtenu cette erreur de référence d’assemblage.

La reconstruction fonctionne mais dans mon cas, je voulais une solution à long terme.

J’ai fait les assemblages référence à la même version du paquet nuget.

Juste un autre cas ici. J’ai eu cette erreur de l’Assistant de débogage géré lors de la première désérialisation d’un fichier XML dans des objects sous VS2010 / .NET 4. Une DLL contenant des classes pour les objects est générée dans un événement de post-génération (éléments de style Microsoft habituels). Travaillé très bien pour plusieurs projets dans la même solution, le problème est apparu lorsque cela a été fait dans un autre des projets. Texte d’erreur:

BindingFailure a été détecté Message: L’assembly avec le nom complet MyProjectName.XmlSerializers n’a pas pu être chargé dans le contexte de liaison ‘LoadFrom’ de AppDomain avec l’ID 1. La cause de l’échec était: System.IO.FileLoadException: impossible de charger le fichier ou l’assembly MyProjectName.XmlSerializers, Version = 1.0.0.0, Culture = neutral, PublicKeyToken = null ‘ou l’une de ses dépendances. La définition de manifeste de l’assembly situé ne correspond pas à la référence de l’assembly. (Exception de HRESULT: 0x80131040)

Étant donné que certaines réponses suggéraient une non-concordance de plate-forme, j’ai remarqué que 3 projets et la solution avaient la configuration “plates-formes mixtes” sélectionnée, et 3 projets ont été compilés pour x86 au lieu d’AnyCPU. Je n’ai pas de code spécifique à la plate-forme (bien que certaines DLL fournies par le fournisseur reposent sur quelques bibliothèques x86). J’ai remplacé toutes les occurrences de x86 dans AnyCPU avec ceci:

 for a in $( egrep '(x86|AnyCPU)' */*.csproj *.sln -l ) ; do echo $a ; sed -i 's/x86/AnyCPU/' $a ; done 

Le projet se construirait alors, mais toutes les options pour exécuter ou déboguer le code seraient grisées. Redémarrer VS ne serait pas utile.

Je suis revenu avec git les références à la bibliothèque x86, juste au cas où, mais a gardé AnyCPU pour tout le code que je comstack.

Suivre F5 ou Démarrer le bouton de débogage est l’application Greyed Out for Winform? J’ai déchargé et rechargé le projet de départ (c’était aussi celui où le problème initial est apparu en premier lieu).

Après cela, tout est rentré en place: le programme fonctionne sans erreur initiale.

Voir http://www.catb.org/jargon/html/R/rain-dance.html , http://www.catb.org/jargon/html/V/voodoo-programming.html ou http: // www. .catb.org / jargon / html / I / incantation.html et des liens.

J’avais le problème de ne pas trouver l’assemblage PayPal et c’était parce que j’avais nommé ma solution PayPal. Je suis sûr que ce ne sera la solution pour personne, mais j’ai pensé que je le partagerais quand même: C # ASP.NET MVC PayPal ne trouve pas d’assemblage

Je viens de supprimer le fichier settings.lic du projet et de commencer à travailler!

Cela m’est arrivé lorsque j’ai mis à jour web.config sans mettre à jour toutes les DLL référencées.

En utilisant un filtre de diff approprié (méfiez-vous du filtre de comparaison de répertoires par défaut de Meld en ignorant les binarys), la différence a été identifiée, les fichiers ont été copiés et tout s’est bien passé.

Il suffit de vérifier votre fichier webconfig et de supprimer ce code: –

     

Juste supprimé le dossier bin et le projet recrée tout et maintenant il fonctionne.

Si vous avez cette erreur en essayant d’append un composant à Visual Studio, – Microsoft.VisualStudio.TemplateWizardInterface – (après avoir essayé d’installer des outils de développement étranges)

considérez cette solution (avec la permission de larocha (merci, qui que vous soyez)):

  1. Ouvrez C: \ Program Files \ Microsoft Visual Studio 9.0 \ Common7 \ IDE \ devenv.exe.config dans un éditeur de texte
  2. Recherchez cette chaîne: ” Microsoft.VisualStudio.TemplateWizardInterfac e”
  3. Commentez l’élément pour qu’il ressemble à ceci:




source: http://webclientguidance.codeplex.com/workitem/15444