Die Manifestdefinition der gefundenen Assembly stimmt nicht mit der Assemblyreferenz überein

751

Ich versuche, einige Komponententests in einer C # Windows Forms-Anwendung (Visual Studio 2005) auszuführen, und erhalte die folgende Fehlermeldung:

System.IO.FileLoadException: Datei oder Assembly 'Utility, Version = 1.2.0.200, Culture = neutral, PublicKeyToken = 764d581291d764f7' oder eine ihrer Abhängigkeiten konnte nicht geladen werden. Die Manifestdefinition der gefundenen Assembly stimmt nicht mit der Assemblyreferenz überein. (Ausnahme von HRESULT: 0x80131040) **

bei x.Foo.FooGO ()

bei x.Foo.Foo2 (String groupName_) in Foo.cs: Zeile 123

bei x.Foo.UnitTests.FooTests.TestFoo () in FooTests.cs: Zeile 98 **

System.IO.FileLoadException: Datei oder Assembly 'Utility, Version = 1.2.0.203, Culture = neutral, PublicKeyToken = 764d581291d764f7' oder eine ihrer Abhängigkeiten konnte nicht geladen werden. Die Manifestdefinition der gefundenen Assembly stimmt nicht mit der Assemblyreferenz überein. (Ausnahme von HRESULT: 0x80131040)

Ich schaue in meine Referenzen und habe nur eine Referenz auf Utility version 1.2.0.203(die andere ist alt).

Irgendwelche Vorschläge, wie ich herausfinden kann, was versucht, auf diese alte Version dieser DLL-Datei zu verweisen?

Außerdem glaube ich nicht, dass ich diese alte Baugruppe überhaupt auf meiner Festplatte habe. Gibt es ein Tool, um nach dieser alten versionierten Assembly zu suchen?

— Leora
quelle

In meinem Fall geschah dies, weil zwei Projekte dieselbe DLL mit unterschiedlichen Versionen luden. (hoffe das hilft jemandem!)

— miguelmpn

461

Der .NET Assembly Loader:

kann 1.2.0.203 nicht finden
habe aber einen 1.2.0.200 gefunden

Diese Assembly stimmt nicht mit der angeforderten überein, und daher wird dieser Fehler angezeigt.

Mit einfachen Worten, es kann die Assembly, auf die verwiesen wurde, nicht finden. Stellen Sie sicher, dass die richtige Baugruppe gefunden werden kann, indem Sie sie in den GAC oder in den Anwendungspfad einfügen. Siehe auch https://docs.microsoft.com/archive/blogs/junfeng/the-located-assemblys-manifest-definition-with-name-xxx-dll-does-not-match-the-assembly-reference .

— Lars Truijens
quelle

19

aber wenn ich mir Referenzen des Projekts ansehe, zeigt es auf 1.2.0.203 ... nichts scheint mehr auf 1.2.0.200 zu deuten

— leora 18.10.08

128

Genau - es sucht nach 1.2.0.203, aber es hat 1.2.0.200 gefunden . Finden Sie heraus, wo sich diese Datei befindet, und ersetzen Sie sie durch die richtige Version.

— Jon Skeet

18

Ich stellte hier eine ähnliche Frage und bekam eine funktionierende Lösung: stackoverflow.com/questions/4187907/…

— Michael La Voie

13

Überprüfen Sie die Referenzversion und prüfen

— Sie

4

Diese Nachricht verwirrt mich jedes Mal. Es scheint rückwärts geschrieben zu sein. Ich würde erwarten, dass es sich über die Version beschwert, die Sie laden möchten, nicht über die gefundene Version. Ich bin froh, dass ich nicht der einzige bin, der etwas falsch macht!

— Greg Woods

91

Sie können einige Maßnahmen ergreifen, um dieses Problem zu beheben. Verwenden Sie zunächst die Windows-Dateisuche, um Ihre Festplatte nach Ihrer Assembly (DLL) zu durchsuchen. Wenn Sie eine Ergebnisliste haben, führen Sie Ansicht-> Details auswählen ... aus und aktivieren Sie dann "Dateiversion". Dadurch wird die Versionsnummer in der Ergebnisliste angezeigt, sodass Sie sehen können, woher die alte Version möglicherweise stammt.

Überprüfen Sie außerdem, wie Lars sagte, Ihren GAC, um festzustellen, welche Version dort aufgeführt ist. In diesem Microsoft-Artikel heißt es, dass im GAC gefundene Assemblys während eines Builds nicht lokal kopiert werden. Daher müssen Sie möglicherweise die alte Version entfernen, bevor Sie alle neu erstellen können. (In meiner Antwort auf diese Frage finden Sie Hinweise zum Erstellen einer Batchdatei, um dies für Sie zu tun.)

Wenn Sie immer noch nicht herausfinden können, woher die alte Version stammt, können Sie die im Lieferumfang von Visual Studio enthaltene Anwendung fuslogvw.exe verwenden, um weitere Informationen zu den Bindungsfehlern abzurufen. Microsoft hat Informationen zu diesem Tool hier . Beachten Sie, dass Sie die Protokollierung aktivieren müssen, indem Sie den HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Fusion\EnableLogRegistrierungsschlüssel auf 1 setzen.

— Seth Petry-Johnson
quelle

19

Vergessen Sie nicht, dass die Dateiversion nicht Teil der Assemblyidentität ist. Die Assembly-Version ist, muss aber nicht mit der Dateiversion identisch sein!

— Lars Truijens

Wenn Sie fuslogvw für Dienste verwenden, lesen Sie blogs.msdn.com/b/junfeng/archive/2004/02/14/72912.aspx

— Nick

Die Suche nach dem Dateinamen hat mein Problem gelöst. Ich hatte eine alte Version der DLL in meinem temporären ASP.Net-Ordner und InstallShield verwendete diese anstelle der aktuellen Version! Saubere Lösung, neu erstellen, PC neu starten hat nichts getan. Funktionierte lokal einwandfrei und explodierte jedes Mal, wenn es bereitgestellt wurde.

— JumpingJezza

Unmittelbar nach dem Erstellen funktioniert meine Website einwandfrei, aber einige Zeit später tritt dieses Problem auf.

— Shavais

Ich habe diese Antwort so bearbeitet, dass stattdessen die Assembly-Version angezeigt wird.

— Worthy7

60

Ich bin gerade selbst auf dieses Problem gestoßen und habe festgestellt, dass das Problem etwas anderes ist als das, auf das die anderen gestoßen sind.

Ich hatte zwei DLLs, auf die mein Hauptprojekt verwies: CompanyClasses.dll und CompanyControls.dll. Ich habe einen Laufzeitfehler erhalten, der besagt:

Datei oder Assembly 'CompanyClasses, Version = 1.4.1.0, Culture = neutral, PublicKeyToken = 045746ba8544160c' oder eine ihrer Abhängigkeiten konnte nicht geladen werden. Die Manifestdefinition der gefundenen Assembly stimmt nicht mit der Assemblyreferenz überein

Das Problem war, dass ich keine CompanyClasses.dll-Dateien mit der Versionsnummer 1.4.1 auf meinem System hatte. Keine im GAC, keine in den App-Ordnern ... keine irgendwo. Ich habe meine gesamte Festplatte durchsucht. Alle CompanyClasses.dll-Dateien, die ich hatte, waren 1.4.2.

Das eigentliche Problem war, dass CompanyControls.dll auf Version 1.4.1 von CompanyClasses.dll verwies. Ich habe gerade CompanyControls.dll neu kompiliert (nachdem ich auf CompanyClasses.dll 1.4.2 verwiesen habe) und dieser Fehler ist für mich verschwunden.

— Nathan Bedford
quelle

2

+1 Ähnliches ist mir passiert, als eine meiner DLLs auf eine ältere Version von Caliburn Micro verweist.

— Jason Massey

Ich auch, Ihre Erfahrung hat mich dahin gebracht, wo ich suchen muss, und ich habe mein Problem behoben.

— Esen

Eine andere Möglichkeit wäre, das CompanyControlsProjekt zu öffnen und mit der rechten CompanyClasses.dllSpecificVersion = false

— Maustaste auf

Dies ist sehr häufig bei Xamarin-Anwendungen der Fall. Ich hatte ein anderes xamarin.forms-Projekt als das xamarin.droid-Projekt. Ich habe gerade Ihren Beitrag gesehen und ihn erkannt.

— Batmaci

Wenn CompanyClasses.dll signiert ist, wird es SpecificVersion = falseallein nicht geschnitten. Du brauchst eine bindingredirect.

— Denise Skidmore

53

Im Folgenden wird jede Assemblyversion auf Version 3.1.0.0 umgeleitet. Wir haben ein Skript, das diese Referenz in der App.config immer aktualisiert, damit wir uns nie wieder mit diesem Problem befassen müssen.

Durch Reflexion können Sie die Assembly publicKeyToken abrufen und diesen Block aus der DLL-Datei selbst generieren.

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

Beachten Sie, dass dies ohne ein XML-Namespace-Attribut (xmlns) nicht funktioniert.

— Yaniv.H
quelle

1

Das hat bei mir funktioniert. Ich habe die 'newVersion = 3.3.3' in 'newVersion = 3.1.0'

— geändert

Am besten nicht den Weg der erneuten Bindung gehen, wenn Sie dies jedoch vermeiden können. Wenn dieser Käfer dich beißt, wird er hart beißen.

— BanksySan

1

Mein Problem war die Tatsache, dass die Weiterleitungen auf nicht vorhandene Assemblys verweisen. Die App.Config enthielt Assemblyinformationen aus den neuesten NuGet-Paketen, die ich installiert hatte. Als ich diese Pakete später heruntergestuft habe, wurde dies NICHT bereinigt. Dies war eine .NET-Standardklassenbibliothek, die von einem 4.7.2-Framework-Unit-Testprojekt getroffen wurde. Das Problem des Unit-Test-Projekts wurde zur Laufzeit vorgestellt.

— D-Sect

@ D-Sekte ist richtig. Wenn Ihre Quellcodeverwaltung anzeigt, dass web.config Änderungen aufweist (weil Sie mit Ihren NuGets gespielt haben), sollten Sie diese BindingRedirects möglicherweise von dort aus unterstützen. Durch ein Downgrade von NuGets werden die Bindungsumleitungen nicht bereinigt

— bkwdesign

45

Wenn Sie Visual Studio verwenden, versuchen Sie "saubere Lösung" und erstellen Sie dann Ihr Projekt neu.

— Bisschen
quelle

14

Dies ist normalerweise die Lösung für mich. Oft löschen binund objtun. Grundsätzlich sitzt etwas, auf das ich mich bezogen habe, immer noch da und versucht, die gleiche Anforderung zu erfüllen. Zum Beispiel eine alte Version, auf die ich direkt verwiesen habe, und die neue Version ist auf NuGet.

— David Betz

Dieses Problem trat bei mehreren DLLs nach dem Abrufen von TFS auf. Diese Lösung hat es für mich behoben.

— Milo

3

Hat für mich gearbeitet. Der Ordner bin amd obj wurde gelöscht und das Problem behoben.

— user1619480

Danke, hat auch für mich funktioniert, nur den Ordner bin gelöscht.

— Der

Für mich war es genug, binOrdner zu löschen . Überraschenderweise habe ich zuvor ohne Erfolg versucht, eine saubere Lösung zu finden und die Lösung neu zu erstellen. Manchmal etwas seltsam.

— Löwe

36

Die anderen Antworten würden für mich nicht funktionieren. Wenn Sie sich nicht für die Version interessieren und nur möchten, dass Ihre App ausgeführt wird, klicken Sie mit der rechten Maustaste auf die Referenz und setzen Sie 'spezifische Version' auf false ... Dies hat bei mir funktioniert. Geben Sie hier die Bildbeschreibung ein

— RayLoveless
quelle

8

Diese Einstellung wirkt sich nur zur Kompilierungszeit aus . Nach dem Kompilieren benötigt es genau dieselbe Assembly-Version, mit der Sie es kompiliert haben. Siehe stackoverflow.com/questions/24022134/…

— Lars Truijens

22

Ich bin gerade auf dieses Problem gestoßen und das Problem war, dass ich eine alte Kopie der DLL in meinem Anwendungs-Debug-Verzeichnis hatte. Vielleicht möchten Sie auch dort (anstelle des GAC) überprüfen, ob Sie es sehen.

— Neal Tibrewala
quelle

Wir haben nur auf einen anderen Server migriert, bei dem dieses Problem aufgetreten ist, da wir Sicherungen durchführen. Arbeitete nach dem Löschen von Sicherungskopien. Danke :)

— Jtuck

22

Ich werde jetzt alle umhauen. . .

Löschen Sie alle <assemblyBinding>Referenzen aus Ihrer .config-Datei und führen Sie diesen Befehl über die NuGet Package Manager-Konsole aus:

Get-Project -All | Add-BindingRedirect

— codeMonkey
quelle

Hat auch für mich gearbeitet. Vielen Dank

— Oleh Udovytskyi

Du hast mir Zeit gespart 👌👌

— Abdu Imam

4

Dies funktioniert nur, wenn das Paketverwaltungsformat packages.config ist. Wenn Sie 2017 csproj ohne packages.config verwenden, funktioniert dies nicht :(

— ManiVI

1

Geist offiziell geblasen

— BGilman

Das ist ein schöner kleiner Trick

— Hexagod

21

Ich habe ein NuGet-Paket hinzugefügt, nur um festzustellen, dass ein Black-Box-Teil meiner Anwendung auf eine ältere Version der Bibliothek verweist.

Ich habe das Paket entfernt und auf die statische DLL-Datei der älteren Version verwiesen, aber die Datei web.config wurde nie aktualisiert von:

<dependentAssembly>
    <assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" />
    <bindingRedirect oldVersion="0.0.0.0-4.5.0.0" newVersion="6.0.0.0" />
</dependentAssembly>

zu dem, worauf es hätte zurückgreifen sollen, als ich das Paket deinstalliert habe:

<dependentAssembly>
    <assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" />
    <bindingRedirect oldVersion="0.0.0.0-4.0.0.0" newVersion="4.5.0.0" />
</dependentAssembly>

— Frattaro
quelle

Ich habe dies gesehen, wo, zumindest für das Entity Framework-Modul, wenn Sie NuGet verwenden, wenn Sie mit der rechten Maustaste auf Ihre Lösung klicken, zu NuGet-Pakete für Lösung verwalten und dann zu Installierte Pakete> Alle gehen, dieses Modul auswählen und Verwalten auswählen Deaktivieren Sie es normalerweise aus Ihrem Projekt. Das sollte solche Dinge bereinigen, ohne es manuell tun zu müssen - vorausgesetzt, der Anbieter hat seine Due Diligence durchgeführt. Aber guter Fang, wie es anscheinend manchmal nicht der Fall ist, wenn Sie ihn so entfernt haben.

— Vapcguy

20

In meinem Fall trat dieser Fehler beim Ausführen einer ASP.NET-Anwendung auf. Die Lösung war:

Löschen Sie die Ordner objund binim Projektordner

Sauber hat nicht funktioniert, Neuaufbau hat nicht funktioniert, alle Referenzen waren in Ordnung, aber es wurde keine der Bibliotheken geschrieben. Nach dem Löschen dieser Verzeichnisse funktionierte alles einwandfrei.

— Levi Fuller
quelle

3

Danke, Levi Fuller. Diese Antwort sollte höher sein; Für meine Situation war es genau richtig! Für mich begann dieser Fehler, als ich eine Sicherungskopie meiner web.config erstellte und Visual Studio diese Konfigurationsdatei anstelle der eigentlichen Konfiguration weiterhin lud, selbst nachdem ich die doppelte Kopie gelöscht hatte. Dies löste es. Vielen Dank.

— BruceHill

Funktioniert auch bei mir. Immer noch unsicher, warum dies funktioniert :(

— KangarooWest

14

In meinem Fall war es eine alte Version der DLL im Verzeichnis C: \ WINDOWS \ Microsoft.NET \ Framework \ ~ \ Temporäre ASP.NET-Dateien \. Sie können entweder die alte Version löschen oder ersetzen oder den Verweis auf die DLL in Ihrem Projekt entfernen und wieder hinzufügen. Grundsätzlich wird in beiden Fällen ein neuer Zeiger auf die temporären ASP.NET-Dateien erstellt.

— Lichtung Mellor
quelle

2

Dies funktionierte für mich, als ich Visual Studio schloss, IIS stoppte und alle temporären ASP.NET-Dateien löschte. Beachten Sie, dass sich auf einem 64-Bit-Computer Dateien im Ordner Framework und Framework64 sowie in den Ordnern .NET 2.0 und 4.0 befinden können!

— Bryan B

Ich habe die Suchfunktion des Windows-Startmenüs verwendet, um alle von meiner Lösung erstellten DLLs zu finden, und dann das gesamte Los gelöscht, wo immer sie gefunden wurden. Ich könnte dies ohne Angst tun, da sie nur während meines Visual Studio-Debuggens erstellt werden sollten. Da VS solche fehlenden DLLs neu erstellt und nichts außerhalb meiner Lösung auf sie verweisen sollte, war dies für mich eine "sichere" Operation.

— Zarepheth

8

Für uns wurde das Problem durch etwas anderes verursacht. Die Lizenzdatei für die DevExpress-Komponenten enthielt zwei Zeilen, eine für eine alte Version der Komponenten, die nicht auf diesem bestimmten Computer installiert waren. Durch Entfernen der älteren Version aus der Lizenzdatei wurde das Problem behoben.

Der ärgerliche Teil ist, dass die Fehlermeldung keinen Hinweis darauf gab, welche Referenz die Probleme verursachte.

— Vater
quelle

2

In meinem Fall enthielt die .resx-Datei eines Formulars nach dem Upgrade auf die neue DevExpress-Version Verweise auf die alte deinstallierte Bibliotheksversion. Ich musste .resx in der Codeansicht öffnen und entweder die Version auf eine neue korrigieren oder die ungültigen Einträge löschen.

— Artemix

5

Dieser exakt gleiche Fehler wird ausgelöst, wenn Sie versuchen, eine späte Bindung mithilfe von Reflection durchzuführen, wenn die Assembly, an die Sie binden, einen starken Namen erhält oder deren Token für den öffentlichen Schlüssel geändert wurde. Der Fehler ist derselbe, obwohl tatsächlich keine Assembly mit dem angegebenen Token für den öffentlichen Schlüssel gefunden wurde.

Sie müssen das richtige Token für den öffentlichen Schlüssel hinzufügen (Sie können es mit sn -T in der DLL erhalten), um den Fehler zu beheben. Hoffe das hilft.

— Guy Starbuck
quelle

1

Bitte erläutern Sie - was ist "sn -T"? Und wo füge ich das Token für den öffentlichen Schlüssel hinzu?

— Moritz Beide

3

"sn.exe" ist ein Tool, das mit Visual Studio geliefert wird. Es ist ein Befehlszeilentool, das über die Visual Studio-Eingabeaufforderung ausgeführt werden kann. Führen Sie einfach die Visual Studio-Eingabeaufforderung (über das Startmenü) aus, navigieren Sie zu dem Ordner, der Ihre Assembly enthält, und geben Sie "sn -T <assembly>" ein, wobei <assembly> der vollständige Name der DLL ist. Dadurch werden die Assembly-Token-Informationen abgerufen. Sobald Sie dies haben, geben Sie die Token-Informationen in die Assembly-ID-Zeichenfolge ein, wenn Sie eine späte Bindung mit Reflection durchführen (dh "Assembly = MyAssembly.dll, Public Key Token = <Token Guid>)

— Guy Starbuck

2

Danke für diese Antwort. Ich habe diesen Fehler beim Verweisen auf einen Konfigurationsabschnitt in meiner App.ini erhalten. Ich hatte die Assembly kürzlich signiert, daher musste das PublicKeyToken = null mit dem neuen (korrekten) Token aktualisiert werden.

— Liam

5

Meins war eine sehr ähnliche Situation wie der von Nathan Bedford, aber mit einer leichten Wendung. Auch mein Projekt hat auf zwei Arten auf die geänderte DLL verwiesen. 1) Direkt und 2) Indirekt durch Verweisen auf eine Komponente (Klassenbibliothek), die selbst einen Verweis auf die geänderte DLL hatte. Jetzt hat mein Visual Studio-Projekt für die Komponente (2) auf die korrekte Version der geänderten DLL verwiesen. Die Versionsnummer der Komponente selbst wurde jedoch NICHT geändert. Infolgedessen konnte die Installation der neuen Version des Projekts diese Komponente auf dem Clientcomputer nicht ersetzen.

Endergebnis: Die direkte Referenz (1) und die indirekte Referenz (2) zeigten auf verschiedene Versionen der geänderten DLL auf dem Client-Computer. Auf meiner Entwicklungsmaschine hat es gut funktioniert.

Lösung: Anwendung entfernen; Löschen Sie alle DLLs aus dem Anwendungsordner. Neu installieren. Einfach wie in meinem Fall.

— Bijimon
quelle

4

Ich werde jemanden von meiner Scherdummheit profitieren lassen. Ich habe einige Abhängigkeiten zu einer völlig separaten Anwendung (nennen wir diese App1). Die DLLs aus dieser App1 werden in meine neue Anwendung (App2) gezogen. Jedes Mal, wenn ich Updates in APP1 mache, muss ich neue DLLs erstellen und diese in App2 kopieren. Gut. . Ich hatte es satt, zwischen zwei verschiedenen App1-Versionen zu kopieren und einzufügen, also habe ich einfach ein 'NEW_'-Präfix zu den DLLs hinzugefügt.

Gut. . . Ich vermute, dass der Erstellungsprozess den Ordner / bin durchsucht und wenn er falsch übereinstimmt, wird die gleiche Fehlermeldung wie oben angegeben angezeigt. Ich habe meine "new_" -Versionen gelöscht und es wurde nur Dandy gebaut.

— Mike Murphy
quelle

4

Mein Problem bestand darin, den Quellcode auf einen neuen Computer zu kopieren, ohne eine der referenzierten Assemblys abzurufen.

Nichts, was ich getan habe, um den Fehler zu beheben, also habe ich in Eile das BIN-Verzeichnis komplett gelöscht. Mein Quellcode wurde neu erstellt und von da an hat es funktioniert.

— AEON Blue Software
quelle

4

Ich möchte nur hinzufügen, dass ich ein grundlegendes ASP.NET MVC 4-Projekt erstellt und DotNetOpenAuth.AspNet über NuGet hinzugefügt habe. Dies führte zu demselben Fehler, nachdem ich auf eine nicht übereinstimmende DLL-Datei für Microsoft.Web.WebPages.OAuth verwiesen hatte.

Um das Problem zu beheben, habe ich eine Update-PackageLösung für einen vollständigen Neuaufbau durchgeführt.

Das hat bei mir funktioniert und ist ein bisschen faul, aber Zeit ist Geld :-P

— Ben Pretorius
quelle

1

Ähnliche Antwort für mich. Update-Package -reinstallInstalliert alle NuGet-Pakete mit derselben Version neu.

— Jess

1

Das ist toll; danke fürs Schreiben. Ich habe all diese anderen großartigen Vorschläge ausprobiert, aber dies war die Lösung, die den Trick gemacht hat. Gott sei Dank für Leute, die immer noch bereit sind, eine alternative Lösung zu veröffentlichen, auch wenn 80 von ihnen verfügbar sind

— Hambone

4

Ich habe diesen Fehler beim Aufbau des Build-Service von Team Foundation Server erhalten. Es stellte sich heraus, dass meine Lösung mehrere Projekte mit verschiedenen Versionen derselben Bibliothek enthielt, die mit NuGet hinzugefügt wurden. Ich habe alle alten Versionen mit NuGet entfernt und die neue als Referenz für alle hinzugefügt.

Team Foundation Server legt alle DLL-Dateien in einem Verzeichnis ab, und es kann natürlich immer nur eine DLL-Datei mit einem bestimmten Namen vorhanden sein.

— cederlof
quelle

Eine andere Möglichkeit besteht darin, auf "NuGet-Pakete für Lösung verwalten ..." zu klicken und sowohl Ihr Testprojekt als auch das zu testende Projekt auf dieselbe (neueste) Version zu aktualisieren.

— Lixonn

4

Meine app.config enthält a

<bindingRedirect oldVersion="1.0.0.0" newVersion="2.0.11.0"/>

für npgsql. Irgendwie ging auf dem Computer des Benutzers meine app.exe.config verloren. Ich bin mir nicht sicher, ob es sich um einen dummen Benutzer, einen Installationsfehler oder ein ausgeflipptes Antivirenprogramm handelt. Das Ersetzen der Datei hat das Problem behoben.

— Thomas
quelle

3

Ich habe gerade einen anderen Grund gefunden, warum ich diesen Fehler bekomme. Ich habe meinen GAC von allen Versionen einer bestimmten Bibliothek befreit und mein Projekt unter Bezugnahme auf eine bestimmte Version erstellt, die zusammen mit der ausführbaren Datei bereitgestellt wurde. Beim Ausführen des Projekts wurde diese Ausnahme bei der Suche nach einer neueren Version der Bibliothek festgestellt.

Der Grund war die Publisher-Richtlinie . Als ich die Bibliotheksversionen von GAC deinstallierte, vergaß ich auch, Publisher-Richtlinien-Assemblys zu deinstallieren. Anstatt meine lokal bereitgestellte Assembly zu verwenden, fand der Assembly Loader die Publisher-Richtlinie in GAC, die ihn aufforderte, nach einer neueren Version zu suchen.

— Ladislav Mrnka
quelle

3

Für mich hat die Konfiguration der Codeabdeckung in der Datei "Local.testtesttings" das Problem "verursacht". Ich habe vergessen, die Dateien zu aktualisieren, auf die dort verwiesen wurde.

— uli78
quelle

3

Nur das Löschen des Inhalts des Bin-Ordners Ihres Projekts und das Neuerstellen der Lösung haben mein Problem gelöst.

— dhiraj1mumbai
quelle

1

Nun, was weißt du, du hast mir gerade aus meinem Elend geholfen, danke in der Tat

— Ronny Mahlangu

2

Bereinigen und neu erstellen Die Lösung ersetzt möglicherweise nicht alle DLLs aus dem Ausgabeverzeichnis.

Ich schlage vor, den Ordner von "bin" in "oldbin" oder "obj" in "oldobj" umzubenennen.

und dann versuchen Sie erneut, Ihre Silution aufzubauen.

Falls Sie DLLs von Drittanbietern verwenden, müssen Sie diese nach erfolgreicher Erstellung in den neu erstellten Ordner "bin" oder "obj" kopieren.

hoffe, das wird für dich funktionieren.

— Ganesh Londhe
quelle

1

Das manuelle Löschen der alten Baugruppe aus dem Ordner und das Hinzufügen des Verweises auf neue Baugruppen kann hilfreich sein.

— rjain
quelle

1

Ich habe den gleichen Fehler erhalten ... In meinem Fall wurde er wie folgt behoben:

Zuerst, als die Anwendung installiert wurde, hatten die Leute hier Microsoft Enterprise Library 4.1 in der Anwendung verwendet.
In der vergangenen Woche wurde mein Computer formatiert und danach, als ich diese Anwendung heute erstellte, gab es einen Fehler, dass die Enterprise Library-Assembly fehlt.
Dann habe ich Microsoft Enterprise Library 5.0 installiert, das ich bei Google als ersten Sucheintrag erhalten habe.
Als ich dann die Anwendung erstellte, gab es den obigen Fehler, dh die Manifestdefinition der gefundenen Assembly stimmt nicht mit der Assemblyreferenz überein.
Nach langem Suchen und Analysieren stellte ich fest, dass die Anwendung auf 4.1.0.0 verweist und die DLL im Ordner bin die Version 5.0.0.0 hat
Dann habe ich die Microsoft Enterprise Library 4.1 installiert.
Die vorherige Referenz (5.0) wurde entfernt und die 4.0-Referenz hinzugefügt.
Erstellt die Anwendung & voila ... es hat funktioniert.

— user4846550
quelle

1

Hier ist meine Methode zur Behebung dieses Problems.

Rufen Sie in der Ausnahmemeldung den Namen der "Problem" -Bibliothek und die "erwartete" Versionsnummer ab.

Suchen Sie alle Kopien dieser DLL in Ihrer Lösung, klicken Sie mit der rechten Maustaste darauf und überprüfen Sie, um welche Version der DLL es sich handelt.

Okay, in diesem Beispiel ist meine DLL definitiv 2.0.5022.0 (daher ist die Versionsnummer der Ausnahme falsch).

Suchen Sie in allen .csproj- Dateien in Ihrer Lösung nach der Versionsnummer, die in der Ausnahmemeldung angezeigt wurde . Ersetzen Sie diese Versionsnummer durch die tatsächliche Nummer aus der DLL.

In diesem Beispiel würde ich dies ersetzen ...

<Reference Include="DocumentFormat.OpenXml, Version=2.5.5631.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL" />

... mit diesem...

<Reference Include="DocumentFormat.OpenXml, Version=2.0.5022.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL" />

Job erledigt !

— Mike Gledhill
quelle

Was ist, wenn in meinen csproj-Dateien keine Version referenziert ist?

— John Demetriou

1

In meinem Fall war das Problem zwischen dem Stuhl und der Tastatur :-)

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)

Zwei oder mehr verschiedene Assemblys wollten eine andere Version der DotNetOpenAuth-Bibliothek verwenden, und das wäre kein Problem. Außerdem wurde auf meinem lokalen Computer eine web.config von NuGet automatisch aktualisiert:

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

Dann wurde mir klar, dass ich vergessen hatte, die neue web.config auf den Produktionsserver zu kopieren / bereitzustellen. Wenn Sie also eine manuelle Methode zum Bereitstellen von web.config haben, überprüfen Sie, ob diese aktualisiert wurde. Wenn Sie eine völlig andere web.config für den Produktionsserver haben, müssen Sie diese abhängigen Assembly-Abschnitte nach Verwendung von NuGet synchron zusammenführen.

— Tomas Kubes
quelle

1

Wenn Sie jemals die Fehlermeldung " Die Manifestdefinition der gefundenen Assembly stimmt nicht mit der Assemblyreferenz überein " erhalten und wenn Sie in VS über die Registerkarte " Projekt"> "NuGet-Pakete verwalten und aktualisieren" aktualisiert haben , können Sie zunächst versuchen, eine andere Version der zu installieren Paket, nachdem Sie die Versionen auf der NuGet Gallery-Seite überprüft und den folgenden Befehl in der Package Manager-Konsole ausgeführt haben:

PM> Install-Package YourPackageName -Version YourVersionNumber 
//Example
PM> Install-Package Microsoft.Extensions.FileProviders.Physical -Version 2.1.0

Obwohl die Antwort nicht direkt mit dem fraglichen Paket zusammenhängt und vor langer Zeit gestellt wurde, ist sie generisch, immer noch relevant und hofft, dass sie jemandem hilft.

— Jaggan_j
quelle

1

Bei mir hat keine Lösung funktioniert. Ich habe versucht, eine saubere Projektlösung zu finden, bin zu entfernen, das Paket zu aktualisieren, das Paket herunterzustufen usw. Nach zwei Stunden habe ich die Standard-App.config aus dem Projekt mit Assemblys geladen und dort die falsche Referenzversion geändert von:

<dependentAssembly>
    <assemblyIdentity name="Microsoft.IdentityModel.Logging" publicKeyToken="31bf3856ad364e35" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-5.5.0.0" newVersion="5.5.0.0" />
</dependentAssembly>

zu:

<dependentAssembly>
    <assemblyIdentity name="Microsoft.IdentityModel.Logging" publicKeyToken="31bf3856ad364e35" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-3.14.0.0" newVersion="5.5.0.0" />
</dependentAssembly>

Danach habe ich das Projekt bereinigt, es erneut erstellt und es hat funktioniert. Keine Warnung kein Problem.

— Mi1anovic
quelle

0

Ich habe diese Fehlermeldung erhalten, weil ich auf eine Assembly verwiesen habe, die denselben Namen wie die Assembly hat, die ich erstellt habe.

Dies wurde kompiliert, aber die referenzierte Assembly wurde mit der aktuellen Projektassembly überschrieben, wodurch der Fehler verursacht wurde.

Um dies zu beheben, habe ich den Namen des Projekts und die verfügbaren Baugruppeneigenschaften geändert, indem ich mit der rechten Maustaste auf das Projekt geklickt und "Eigenschaften" ausgewählt habe.

— Dan
quelle