L'assemblée manifeste définition 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 à Utility version 1.2.0.203 (l'autre est vieux).

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

D'ailleurs, 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?

InformationsquelleAutor leora | 2008-10-18

c#compiler-errors dependencies reference version

433

L' .NET de l'Assemblée chargeur est impossible de trouver 1.2.0.203, mais a trouvé un 1.2.0.200. Cette assemblée ne correspond pas à ce qui avait été demandé et, par conséquent, vous obtenez cette erreur. En termes simples, il ne peut pas trouver l'assemblée qui a été référencée. Assurez-vous qu'il peut trouver la droite de l'assemblée en la mettant dans le GAC ou dans le chemin de l'application. Voir aussi http://blogs.msdn.com/junfeng/archive/2004/03/25/95826.aspx.
- mais quand je regarde les références du projet, il est pointé à 1.2.0.203 .. . rien ne semble indiquer une 1.2.0.200 plus
- Exactement - c'est cherche pour 1.2.0.203, mais trouvé 1.2.0.200. Trouver où ce fichier est et de le remplacer avec la bonne version.
- J'ai posé une question similaire ici et a obtenu une solution qui fonctionne: stackoverflow.com/questions/4187907/...
- Vérifiez les références de la version, puis de regarder si c'est la même chose dans les packages.config et Web.config
- détails sur le déroulement fuslogw comme indiqué dans le lien ci-dessus pour JunFeng blog blogs.msdn.com/b/suzcook/archive/2003/05/29/57120.aspx
- Puis-je supprimer le contenu de la GAC et mon projet de reconstruction de ces fichiers?
- Dans mon cas, en vertu de Construire > Publier, j'ai eu "Supprimer tous les fichiers existants avant de publier" cochée, alors qu'il était en utilisant une ancienne version de la DLL sur le serveur et n'était pas de l'écraser avec la nouvelle version j'ai eu localement. Une fois que j'ai vérifié qu'il a poussé la bonne version de IIS et il fixe.
- Web.config n'a pas de match de paquets.confg, merci @zdarsky.peter
- J'ai eu cette erreur avec un package nuget qui était totalement absent. Quand je suis allé à nuget et installé le package de l'erreur a été corrigée.
- Truijens comment savez-vous qu'il a trouvé 1.0.200? Je ne peux pas voir 200 mentionné dans le cas des OP stacktrace?
- Il dit littéralement dans le Message de l'Exception: Version=1.2.0.200
- Truijens ah oui! Ne savais pas que l'
- Ce message me confond à chaque fois. Il semble être écrits à l'envers. Je m'attends à se plaindre à propos de la version que vous avez demandé à charge, pas la version qu'il trouve. Heureux, je ne suis pas le seul qui est faux!
- J'ai cherché la délinquance assemblée nuget, installé (avec une nouvelle version) et le problème a disparu.
- J'étais même erreur sur l'Azur de la fonction du projet et avec l'aide de fuslogvw.exe @ra170 identifier que assemblyIdentity Microsoft.Azure.Le stockage.Commun" est absent de la touche func.exe.Config. J'ai donc ajouté ceci : <dependentAssembly> <assemblyIdentity name="Microsoft.Azure.Storage.Common" publicKeyToken="31bf3856ad364e35" culture="neutral" /> <bindingRedirect oldVersion="0.0.0.0-9.0.0.0" newVersion="9.0.0.0" /> </dependentAssembly>
InformationsquelleAutor Lars Truijens
89

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, Affichage->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 Lars dit, 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 est à venir, 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 la HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Fusion\EnableLog clé de registre à 1.
- N'oubliez pas que la Version du Fichier ne fait pas partie des assemblées de l'identité. La Version de l'Assembly est, mais ne doit pas être la même que la Version du Fichier!
- Si vous utilisez fuslogvw pour les services de lecture de blogs.msdn.com/b/junfeng/archive/2004/02/14/72912.aspx
- La recherche pour le nom de fichier a résolu mon problème. J'avais une ancienne version de la dll dans mon Temporaire ASP.Net dossier et InstallShield a l'aide de qui, au lieu de la version à jour! Solution propre, reconstruire, redémarrer le PC n'a rien fait. A bien fonctionné localement et fait exploser à chaque fois qu'il a été déployé.
- Immédiatement après la construction de mon site fonctionne très bien, mais un peu plus tard, ce problème surgit.
- J'ai édité cette réponse-à-dire la version de l'assembly à la place.
InformationsquelleAutor Seth Petry-Johnson
54

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:

N'a pas pu 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

Des difficultés, 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.
- +1 quelque Chose de similaire qui m'est arrivé lorsque j'ai un de mes Dll référence à une ancienne version de Caliburn Micro.
- moi aussi, votre expérience a suscité moi où j'ai besoin de regarder et j'ai obtenu mon numéro fixe.
- Une autre option serait d'ouvrir la CompanyControls projet, cliquez-droit sur le CompanyClasses.dll de référence --> propriétés - > SpecificVersion = false
- c'est très souvent le cas sur xamarin applications. J'ai eu xamarin.projet de formulaires différents de xamarin.droid projet. Je viens de voir votre post et je l'ai reconnu.
- Si CompanyClasses.dll est signé, puis SpecificVersion = false seul n'est pas suffisant. Vous aurez besoin d'un bindingredirect.
InformationsquelleAutor Nathan Bedford
50

Suivantes redirige la version de l'assembly à la version 3.1.0.0. Nous avons un script qui va toujours de mise à jour de cette référence dans l'Application.config donc nous n'avons jamais avoir à traiter avec de nouveau ce problème.

Par la réflexion, vous pouvez obtenir de l'assemblée publicKeyToken et générer ce pâté de maisons de la .dll fichier 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>
```
Noter que sans un espace de noms XML attribut xmlns) cela ne fonctionnera pas.
- Cela a fonctionné pour moi. J'ai changé le "nouvelleversion=3.3.3' à 'nouvelleversion=3.1.0'
- Préférable de ne pas aller en bas de la reconsolidation du droit de l'itinéraire si vous pouvez l'éviter si. Lorsque que le bug vient de vous mordre, il va mordre dur.
- Mon problème était le fait que les redirections ont été pointant vers inexistante assemblées.L'App.Config tenue de l'assemblée info à partir de la dernière packages NuGet je l'avais installé. Quand j'ai rétrogradé ces paquets plus tard, il n'a PAS nettoyer cette. C'était une .NET standard de la bibliothèque de classe d'être frappé par un 4.7.2 cadre de projet de tests unitaires. Le projet de test d'unité du sujet présenté lors de l'exécution..
- est droit. Si votre source de contrôle indique que le web.config a des changements (parce que vous avez à jouer avec votre NuGets), vous pourriez être sage pour ceux bindingRedirects sortir de là. La rétrogradation des NuGets ne va pas nettoyer la liaison redirige
InformationsquelleAutor Yaniv.H
38

Si vous utilisez Visual Studio, essayer de "nettoyer la solution" et puis reconstruire votre projet.
- Je serais très surpris si cela fait une différence...
- C'est généralement la solution pour moi. Souvent, la suppression de bin et obj le faire. Fondamentalement, quelque chose que j'ai utilisé pour faire référence est toujours assis là, à tenter de répondre à la même exigence. Par exemple, une ancienne version étant quelque chose que j'ai référencé directement et la nouvelle version en cours sur NuGet.
- Rencontré ce problème pour plusieurs Dll après le tirage de TFS. Cette solution fixe pour moi.
- A travaillé pour moi. Supprimé de la corbeille amd dossier obj et résolu le problème.
- Merci, a fonctionné pour moi aussi, il suffit de supprimer le dossier bin.
InformationsquelleAutor Tad
32

Les autres réponses ne fonctionne pas pour moi. Si vous n'avez pas de soins sur la version et vous voulez juste votre application à exécuter, puis un clic droit sur la référence et la valeur "version spécifique" pour de faux...Cela a fonctionné pour moi.
- Ce paramètre n'a d'effet que sur compilation. Après il est compilé, il aura besoin d'exactement la même version de l'assembly avec qui vous avez compilé. Voir stackoverflow.com/questions/24022134/...
InformationsquelleAutor RayLoveless
21

Je viens de tombé sur cette question et le problème est que j'avais une vieille copie de l' .dll dans mon application debug. Vous pouvez aussi vérifier qu'il n'y (au lieu de le GAC) pour voir si vous la voyez.
- Nous venons de migre vers un autre serveur eu ce problème parce que nous avons de conserver des sauvegardes. Travaillé après la suppression des copies de sauvegarde. Merci 🙂
InformationsquelleAutor Neal Tibrewala
20

J'ai ajouté un package NuGet, pour réaliser une boîte noire partie de ma demande est de la référence à une ancienne version de la bibliothèque.

J'ai supprimé le paquet et fait référence à l'ancienne version statique du fichier DLL, mais le web.fichier de configuration 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>
```
à ce qu'il devrait avoir été 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>
```
- J'ai vu ça où, au moins pour l'Entité Cadre du module lorsque que vous utilisez NuGet, si vous cliquez droit sur votre solution, accédez à Gérer les Packages NuGet pour la Solution, puis Installé les Packages > Tous, sélectionnez ce module, sélectionnez Gérer, vous pouvez le désélectionner de votre projet. Qui doit nettoyer ce genre de choses sans avoir à le faire manuellement --- en supposant que le vendeur a fait preuve de diligence raisonnable. Mais bon catch comme apparemment parfois, ils ne le font pas, si c'est comment vous l'avez supprimé.
InformationsquelleAutor frattaro
15

Dans mon cas, cette erreur s'est produite lors de l'exécution d'un ASP.NET application.
La solution a été de:
1. Supprimer la obj et bin dossiers dans le dossier du projet
Propre ne fonctionne pas, de reconstruire n'ai pas de travail, toutes les références ont été très bien, mais ce n'était pas l'écriture de l'une des bibliothèques. Après la suppression de ces répertoires, tout a fonctionné parfaitement.
- Merci, Levi Fuller.Cette réponse doit être plus haut; pour ma situation, il était sur place! Pour moi, cette erreur a commencé quand j'ai fait une copie de sauvegarde de mon site web.config et Visual Studio gardé le chargement de ce fichier de config à la place de la config, même après que j'ai supprimé la copie. Cette résolu. Merci.
- Fonctionne pour moi aussi. Savez toujours pas pourquoi cela fonctionne si 🙁
InformationsquelleAutor Levi Fuller
14

Dans mon cas, c'était une vieille version de la DLL dans C:\WINDOWS\Microsoft.NET\Framework\~\Temporary ASP.NET Files\ répertoire. Vous pouvez supprimer ou de remplacer l'ancienne version, ou vous pouvez supprimer et ajouter la référence à la DLL dans votre projet. En gros, soit la façon de créer un nouveau pointeur temporaire ASP.NET les Fichiers.
- Cela a fonctionné pour moi lorsque j'ai fermé Visual Studio, arrêté IIS, et de supprimer toutes les temporaires ASP.NET les fichiers. Notez qu'il peut y avoir des fichiers dans le Cadre et Framework64 dossier si sur ordinateur 64 bits, ainsi que dans l' .NET 2.0 et 4.0 dossiers!
- J'ai utilisé le Menu Démarrer de Windows fonction de recherche pour trouver toutes les Dll créé par ma solution, puis supprimé, l'ensemble du lot, où ils ont été trouvés. Je pourrais le faire sans crainte, car ils ne devraient être créés au cours de mon débogage Visual Studio. Comme VS permettra de reconstruire une telle Dll manquantes et rien en dehors de ma solution devrait être leur référencement, c'était un "coffre-fort" de l'opération pour moi.
InformationsquelleAutor Glade Mellor
12

Je vais souffler l'esprit de tous, dès maintenant . . .

Supprimer tous les <assemblyBinding> références de votre .fichier de config, puis exécutez cette commande à partir du Gestionnaire de Package NuGet console:
```
Get-Project -All | Add-BindingRedirect
```
- Cela est correct. Des œuvres.
- A travaillé pour moi aussi. Merci
- vous avez sauvé mon temps
- cela ne fonctionne que lorsque le package format de gestion des paquets.config, si vous utilisez 2017 csproj sans paquets.config, il doenst travail 🙁
InformationsquelleAutor codeMonkey
8

Pour nous, le problème a été causé par quelque chose d'autre. Le fichier de licence de DevExpress composants inclus deux lignes, l'une pour une ancienne version des composants qui n'a pas été installé sur cet ordinateur. Dépose de l'ancienne version dans le fichier de licence a résolu le problème.

L'ennuyeux, c'est que le message d'erreur n'a donné aucune indication à ce que la référence a été à l'origine des problèmes.
- Dans mon cas, après la mise à niveau à nouveau DevExpress version, l' .fichier resx d'un formulaire contenait des références à de vieux désinstallé version de bibliothèque. J'ai dû ouvrir .resx dans le code de la vue et de corriger la version à nouveau un ou supprimer les entrées non valides.
InformationsquelleAutor Sire
5

C'est exactement la même erreur est levée si vous essayez à la fin de lier l'aide de la réflexion, si l'assemblée en vous contraignant à obtient un nom fort ou a son public-clés jeton changé. L'erreur est la même, même si il n'y a pas réellement de toute assemblée trouvé avec le jeton de clé publique.

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. Espérons que cette aide.
- Veuillez préciser - qu'est-ce que "sn -T"? Et où puis-je ajouter le jeton de clé publique?
- "sn.exe" est un outil qui est fourni avec Visual Studio, c'est un outil de ligne de commande qui peut être exécuté à partir de l'invite de commande Visual Studio. Il suffit de lancer l'invite de commande Visual Studio (à partir du menu démarrer), naviguez jusqu'au dossier qui contient votre assemblée, et le type "sn -T <l'assemblée>", où <l'assemblée> est le nom complet de la dll. Il obtient de l'Assemblée "Jeton" de l'information. Une fois que vous avez cela, quand vous faites la fin de la liaison avec la réflexion, entrez le jeton d'info dans l'assemblée de l'id de chaîne (c'est à dire, "Assembly=MyAssembly.dll, Jeton de Clé Publique=<jeton guid>)
- Merci pour cette réponse. J'ai été faire cette erreur lors de la référence à une Section de Configuration dans mon Application.ini. J'ai eu récemment signé l'assemblée, de sorte que le PublicKeyToken=null a dû être mis à jour avec la nouvelle (correct) jeton.
InformationsquelleAutor Guy Starbuck
5

La mienne était une situation très semblable à ce poste par Nathan Bedford, mais avec une légère torsion. Mon projet trop référencé le changement de la dll de deux façons. 1) Directement et 2) Indirectement, par référence à un composant (bibliothèque de classe) qui lui-même avait une référence à l'évolution de la dll. Maintenant, mon projet Visual studio pour le composant(2) fait référence à la version correcte de la modification de la dll. Toutefois, le numéro de version de la compnent lui-même n'a PAS été modifié. Et comme un résultat de l'installation de la nouvelle version du projet a échoué à remplacer ce composant sur la machine client.

Résultat final: référence Directe (1) et Indirectes de référence(2) ont été pointant vers les différentes versions de la modification de la dll à l'ordinateur client. Sur ma machine de dev il a bien fonctionné.

Résolution: Supprimer l'application; Supprimer toutes les DLL dans le dossier de l'application; Re-installer.Simple comme ça dans mon cas.

InformationsquelleAutor Bijimon
4

Je vais laisser quelqu'un bénéfice de mes cisaillement de la stupidité. J'ai quelques dépendances à un tout autre application (appelons cette App1). La dll à partir de ce App1 sont tiré dans ma nouvelle application (App2). Toutes les fois que je fais des mises à jour dans APP1, je dois créer de nouveaux dll et de les copier dans App2. Bien. . .Je suis fatigué de copier et coller entre 2 App1 versions, donc j'ai simplement ajouté un "NEW_' préfixe de la dll.

Bien. . . Je devine que le processus de construction scanne le dossier /bin et lorsqu'elle correspond à quelque chose de mal, il barfs avec le même message d'erreur comme indiqué ci-dessus. J'ai supprimé mon "new_" versions et il construit juste dandy.

InformationsquelleAutor Mike Murphy
4

Mon problème a été de copier le code source d'une nouvelle machine sans tirer sur tous les assemblys référencés.

Rien que je n'ai corrigé l'erreur, donc, dans la précipitation, j'ai supprimé le répertoire BIN tout à fait. Reconstruit mon code source, et il a travaillé par la suite.

InformationsquelleAutor AEON Blue Software
4

Je voudrais juste ajouter que j'ai été la création d'une base ASP.NET MVC 4 du projet et a ajouté DotNetOpenAuth.Le réseau via NuGet. Cela a donné le même message d'erreur après que j'ai référencé une désadaptation fichier DLL pour Microsoft.Web.Les pages web.OAuth.

Pour le fixer, j'ai fait un Update-Package et nettoyé la solution pour une reconstruction complète.

Qui a fonctionné pour moi et est une sorte de manière paresseuse, mais le temps est de l'argent:-P
- Similaire réponse pour moi. Update-Package -reinstall re-installe tous les paquets NuGet à la même version.
- C'est super; merci pour l'affichage. J'ai essayé tous les autres excellentes suggestions, mais c'est la solution qui a fait le tour. Dieu merci pour les gens qui sont toujours prêts à poster une autre solution, même lorsqu'il y a 80 d'entre eux disponibles
InformationsquelleAutor Ben Pretorius
4

J'ai eu cette erreur lors de la construction sur le Serveur Team Foundation build-service. Il s'est avéré que j'avais de multiples projets dans ma solution à l'aide de différentes versions de la même bibliothèque ajouté avec NuGet. J'ai enlevé toutes les anciennes versions avec NuGet et a ajouté un nouveau titre de référence pour tous.

Team Foundation Server met tous les fichiers DLL dans un répertoire, et il peut seulement être un fichier DLL d'un certain nom à un temps de parcours.
- Une autre façon est de cliquer sur "Gérer les packages NuGet pour la solution..." et de mettre à jour votre projet de test et le projet en cours de tests sur le même (le plus récent) de la version.
InformationsquelleAutor cederlof
4

Mon application.config contient un
```
<bindingRedirect oldVersion="1.0.0.0" newVersion="2.0.11.0"/>
```
pour npgsql. En quelque sorte sur la machine de l'utilisateur, l'une de mes applications.exe.config a disparu. Je ne suis pas sûr si c'était un idiot de l'utilisateur, l'installateur glitch, ou wacked anti-virus encore. En remplaçant le fichier a résolu le problème.

InformationsquelleAutor Thomas
3

Je viens de trouver une autre raison possible pour obtenir cette erreur. J'ai nettoyé mon GAC a partir de toutes les versions d'une bibliothèque spécifique et construit mon projet avec référence à la version spécifique du déploiement avec l'exécutable. Quand je lance le projet, j'ai cette exception à la recherche d'une nouvelle version de la bibliothèque.

La raison en était l'éditeur de stratégie de. Lorsque je l'ai désinstallé de la bibliothèque de versions à partir de GAC j'ai oublié de désinstaller l'éditeur de la politique des assemblages ainsi donc, au lieu d'utiliser mon déployé localement assemblée l'assemblée chargeur trouvé d'éditeur de la politique dans le GAC qui l'a raconté à la recherche d'une version plus récente.

InformationsquelleAutor Ladislav Mrnka
3

Me la couverture de code de configuration dans le "Local.testtesttings" fichier "provoqué" le problème. J'ai oublié de mettre à jour les fichiers qui ont été référencé il.

InformationsquelleAutor uli78
2

Simplement effacer le contenu de votre dossier bin du projet et de reconstruire la solution a résolu mon problème.
- Qu'est-ce que vous savez, vous venez de m'a aidée à sortir de ma misère, merci bien
InformationsquelleAutor dhiraj1mumbai
2

nettoyer et reconstruire la solution peut pas remplacer toutes les dll du répertoire de sortie.

ce que je vous suggère, c'est d'essayer de renommer le dossier "bin" à "oldbin" ou "obj" à "oldobj"

et puis essayez de construire votre silution de nouveau.

encas si vous utilisez un tiers dll ceux que vous devez copier dans le nouvellement créé "bin" ou "obj" dossier après la réussite de la construction.

espère que cela fonctionnera pour vous.

InformationsquelleAutor Ganesh Londhe
1

Manuellement la suppression de l'ancienne assemblée de l'emplacement du dossier de et puis d'ajouter la référence à de nouveaux assemblages pourrait aider.

InformationsquelleAutor rjain
1

J'ai eu le même message d'erreur...
Dans mon cas, il a obtenu réglée comme suit:
- D'abord, lorsque l'application a été installée, puis les gens ici avaient utilisé Microsoft Enterprise Library 4.1 dans l'application.
- Dans la semaine précédente, mon ordinateur a été formaté & après qu'aujourd'hui, quand j'ai construit cette application, puis il m'a donné une erreur que de l'Entreprise de la Bibliothèque de l'assemblée est manquant.
- Puis j'ai installé Microsoft Enterprise Library 5.0, qui je suis sur Google comme première entrée de recherche.
- Puis, quand j'ai construit l'application puis il m'a donné l'erreur ci-dessus, c'est à dire L'assemblée manifeste définition ne correspond pas à la référence d'assembly.
- Après beaucoup de recherche travail & analyse, j'ai trouvé que l'application est en se référant 4.1.0.0 & la DLL dans le dossier bin était de la version 5.0.0.0
- Ce que j'ai fait puis j'ai installé le Microsoft Enterprise Library 4.1.
- Supprimé la référence précédente(5.0) & ajout de la version 4.0 de référence.
- Construit l'application & voila...il a travaillé.
InformationsquelleAutor user4846550
1

Voici ma méthode de résolution de ce problème.
1. À partir du message de l'exception, obtenir le nom de "problème" de la bibliothèque et les "attendus" numéro de version.
1. Trouver toutes les copies de que .dll dans votre solution, cliquez-droit sur eux, et de vérifier la version de l' .dll il est.
Ok, donc dans cet exemple, mon .dll est certainement 2.0.5022.0 (donc à l'Exception du numéro de version est mauvaise).
1. De recherche pour le numéro de version qui a été indiqué dans le message d'Exception dans tous les .csproj fichiers dans votre solution. Remplacer ce numéro de version avec le nombre réel à partir de la dll.
Donc, dans cet exemple, je voudrais remplacer cette...
```
<Reference Include="DocumentFormat.OpenXml, Version=2.5.5631.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL" />
```
... avec cette...
```
<Reference Include="DocumentFormat.OpenXml, Version=2.0.5022.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL" />
```
Travail !
- que faire si mon csproj fichiers n'ont pas de version référencée?
InformationsquelleAutor Mike Gledhill

Dans mon cas, le problème est 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)

De deux ou de plusieurs assemblées voulais utiliser une version différente de la DotNetOpenAuth bibliothèque, et qui ne serait pas un problème. En outre, sur mon ordinateur en local un site 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>

Puis j'ai réalisé que j'avais oublié de copier/déployer le nouveau site web.config pour le serveur de production. Donc, si vous avez le manuel de moyen de déployer des web.config, vérifier qu'il est bien mis à jour. Si vous avez complètement différent de web.config pour un serveur de production, vous avez pour fusionner ces dependentAssembly section sync après l'utilisation de NuGet.

InformationsquelleAutor Tomas Kubes

1

Si jamais vous obtenez une erreur comme "L'assemblée manifeste définition ne correspond pas à la référence d'assembly" et si vous avez mis à jour via Projet > Gérer les Packages NuGet et onglet mise à Jour de VS, la première chose que vous pourriez faire est d'essayer d'installer une autre version d'un paquet, après vérification des versions de NuGet page de la Galerie et de l'exécution de l'suivantes de commande de la Console du Gestionnaire de Package:
```
PM> Install-Package YourPackageName -Version YourVersionNumber 
//Example
PM> Install-Package Microsoft.Extensions.FileProviders.Physical -Version 2.1.0
```
Bien que la réponse n'est pas directement liée à l'application en question et il a été demandé le chemin du retour, c'est une sorte de générique, toujours d'actualité et j'espère que ça aide quelqu'un.

InformationsquelleAutor Jaggan_j
0

J'ai reçu ce message d'erreur en raison de la référence à une assemblée qui avait le même nom que l'assemblée j'ai été la construction.

Ce compilé, mais il a remplacé l'assembly référencé avec les projets en cours de montage ainsi l'origine de l'erreur.

Pour le fixer, j'ai changé le nom du projet, et l'assemblée des propriétés disponibles via le bouton droit sur le projet et en choisissant "Propriétés".

InformationsquelleAutor dan
0

Dans votre AssemblyVersion dans AssemblyInfo.cs fichier, utilisez un fixe, le numéro de version au lieu de spécifier *. L' * va changer le numéro de version sur chaque compilation. C'était le problème de cette exception dans mon cas.

InformationsquelleAutor DevXP
0

J'ai rencontré ce problème lors de l'utilisation d'un module interne de référentiel. J'avais ajouté le paquet principal pour le dépôt interne, mais pas les dépendances du paquet. Assurez-vous d'ajouter toutes les dépendances, les dépendances des dépendances, récursive, etc à votre référentiel interne ainsi.

InformationsquelleAutor ScubaSteve
0

J'ai eu le même problème aujourd'hui, ce qui m'a empêché d'effectuer Ajoutez-la Migration après j'ai fait des modifications dans le Cadre de l'Entité.

J'ai eu deux projets dans ma solution, appelons-les "Client" et "Données" - un projet de bibliothèque de classes qui a retenu mon EF modèles et le contexte. Le Client référencé le projet de Données.

J'avais signé les deux projets, et puis plus tard, a apporté des modifications à un modèle EF. Après avoir retiré la signature j'ai été en mesure d'ajouter les migrations, et pourrait ensuite signé le projet de nouveau.

J'espère que cela peut être utile pour quelqu'un, lui épargnant de longues frustration..

InformationsquelleAutor Thomas Fauskanger
0

Cela peut également se produire si vous utilisez les deux AssemblyInfo.cs avec le AssemblyVersion balises et votre .fichier csproj a avec une valeur différente. Soit par correspondance de la AssemblyInfo ou la suppression de la section, tous ensemble, le problème disparaît.

InformationsquelleAutor netniV
0

OK, une réponse de plus. J'ai déjà créé mon application 64 bits et changé le chemin de sortie (Projet/Propriétés/Construire/de Sortie/Output Path) en conséquence. Récemment, j'ai changé l'application de 32 Bits (x86), la création d'un nouveau chemin de sortie. J'ai créé un raccourci vers où je pensée la compilation .exe allait. Peu importe ce que j'ai changé sur la source, il a obtenu le manifeste qui ne correspond pas d'erreur. Après environ une heure de frustration, il m'est arrivé de vérifier la date et l'heure de l' .exe fichier, vu qu'il était ancien évidemment le référencement vieux .dll. J'ai été la compilation de l'application dans l'ancien répertoire et mon raccourci faisait référence à la plus récente. Changé le chemin de sortie à où la .exe devrait aller, a couru le raccourci et l'erreur a disparu. (gifles front)

InformationsquelleAutor OldDog
0

J'ai eu ce problème après avoir commencé à utiliser InstallShield. Même si l'ordre de la génération a montré le projet d'installation de la dernière, c'était la construction de l'ordre.

J'ai corrigé ce par tout autre projet dépend - il forcé l'installation de construire en dernier et donc enlevé mon assemblée de désadaptation. J'espère que cette aide.

InformationsquelleAutor Tim
0

La question a déjà une réponse, mais si le problème a eu lieu en package NuGet dans les différentes versions de la même solution, vous pouvez essayer ce qui suit.

Ouvrir le Gestionnaire de Package NuGet, comme vous le voyez mon projet de service version est différente de celle des autres.

Puis mettre à jour des projets qui contiennent une ancienne version de votre colis.

InformationsquelleAutor erhan355
0

J'ai eu un problème similaire lors de la tentative de mise à jour d'un fichier DLL de mon site web.

Cette erreur était en cours, quand j'ai simplement copié ce fichier DLL dans le dossier bin via FTP.

J'ai résolu ce problème en faisant:
1. l'arrêt de la web-site;
2. besoin de la copie de fichier DLL/DLL-files;
3. de commencer le site web
InformationsquelleAutor magicmanam
0

J'ai été confrontée au même problème lors de l'exécution de mon unité de cas de tests.

L'erreur indique clairement le problème: quand nous essayons de nous charger de l'assemblée, l' .NET de l'assemblée chargeur essaie de charger ses visées assemblées en fonction de son manifeste de données (appelé nom de l'assembly, jeton de clé publique, la version).

De vérifier les données du manifeste:
1. Ouvrir l'invite de commande Visual Studio,
2. Type 'ildasm" et faire glisser l'assemblage de la ILDASM fenêtre et ouvrez MANIFESTE vue. Parfois MANIFESTE contient une assemblée avec deux versions ancienne version ainsi que la nouvelle version(comme Utility, Version=1.2.0.200 et Utility, Version=1.2.0.203). En réalité, l'assemblée est Utility, Version=1.2.0.203(new version), mais depuis le manifeste contient même Utility, Version=1.2.0.200(old version), .NET de l'assemblée chargeur essaie de trouver ce de version de fichier DLL, ne parvient pas à trouver et donc throws exception.
Pour résoudre ce problème, il suffit de glisser chacun des projets dépendant assemblées à la ILDASM fenêtre séparément, et vérifiez dépendante de l'assemblée détient les données manifeste avec l'ancienne version de l'assembly. Simplement de reconstruire ce dépendante de l'assemblée et de la renvoyer à votre projet.
- Malheureusement, je ne peux pas faire glisser l'assemblée à ildasm depuis l'erreur empêche l'assemblée de...
- Cela semble prometteur, mais je ne comprends pas comment le résoudre. J'ai trouve un projet dans ma solution qui a deux versions du Système.Web.Mvc. Quand je le reconstruire, il contient toujours deux versions. Comment puis-je me débarrasser de la référence à l'ancienne version?
InformationsquelleAutor shan
0

Le problème avec moi, c'était qu'il y avait des vieux dll dployed qui ont été supprimés dans une nouvelle construction.
Pour le fixer, j'ai juste coché la case pour supprimer des fichiers supplémentaires à destination lors de la publication.
Supprimer des fichiers supplémentaires à destination

InformationsquelleAutor Bellatorius
0

Eu le même problème mentionné dans ce post "des suggestions sur la façon dont je comprendre ce qui est en train d'essayer de référence de cette ancienne version de ce fichier DLL?"

Nécessaire que l'assemblée se réfère encore vieux client ODATA 6.15.0 , le ildasm a permis de préciser pour moi (sans la base de code d'accès, uniquement via déployé pkg sur le serveur).

Capture d'écran ci-dessous pour un résumé rapide.

DeveloperPackge si vous ne disposez pas ildasm.exe
https://www.microsoft.com/net/download/visual-studio-sdks

InformationsquelleAutor Nara
0

Cette même erreur a été de surfaçage pour moi dans mes Tests Unitaires projet et entraînant l'échec de tests. J'ai vérifié la version de l'assembly j'ai été en utilisant de l'assemblée de l'explorateur et de vérifier le contenu de la runtime/dependentassembly balises et a réalisé une version différente de l'assemblée, je l'utilisais était encore référencée là. Parce que c'était la seule directive dans mes tests en projet app.config, j'ai juste essayé de la suppression de la totalité de l'app.fichier de configuration, la reconstruction de la solution, et qui a fait le tour! Pas plus d'erreurs de référence pour moi 🙂

InformationsquelleAutor Ryan
0

J'ai été faire:

Impossible de charger le fichier ou l'assembly 'XXX-nouveau' 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)

C'était parce que j'ai changé le nom de l'assemblée de XXX.dll à XXX-new.dll. Retour nom retour à l'origine correction de l'erreur.

InformationsquelleAutor mimo
0

vérifiez les licences.licx dans les propriétés du projet, vous trouverez la mauvaise version.... il a travaillé pour moi dans le rapport actif références

InformationsquelleAutor Marzie Keshavarz
0

Qui m'est arrivé pour System.ValueTuple

Erreur inattendue n'a pas Pu charger le fichier ou l'assembly 'Système.ValueTuple,
Version=4.0.1.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51 " ou
l'une de ses dépendances. Le système ne peut pas trouver le fichier spécifié.

Résolu par l'installation d' .NET Framework 4.7.2 Runtime sur la machine, l'erreur s'est produite sur. Simple et pas besoin d'ajouter bindingRedirect, la modification du GAC ou le déclassement de packages NuGet etc.

https://dotnet.microsoft.com/download/dotnet-framework/net472

InformationsquelleAutor Ogglas
-4

Essayez d'ajouter ce qui manque pour le global assembly cache.
- En fait, je n'ai pas l'downvotes. Lorsqu'une référence est manquante, parfois de l'ajouter à la GAC EST en fait la réponse, en SUPPOSANT que c'est où la référence est souligné. Je suis d'accord que cette réponse aurait pu être libellée comme une réponse directe à l'auteur de la question, un lien sur la façon de l'obtenir dans le GAC, mais il ne faut pas pénaliser pour une réponse générale, surtout avec l'autre ramification ici, déjà. Je ne vois DONC comme un tas de réponses possibles pour le type d'erreur, et pas seulement à un scénario spécifique. Et ils n'ont pas plus de 50 rep, donc ils ne peuvent pas ajouter un commentaire à la question ou les postes (qui à mon humble avis devrait changer).
InformationsquelleAutor nikonica
-4

À droite, cliquez sur la référence dans VS "Version Spécifique" True à la propriété.
- Je pense que tu veux dire faux.
InformationsquelleAutor Adam

Vous devez vous connecter pour publier un commentaire.