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

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?

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 .

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.

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.

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.

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

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.

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.

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

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>

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

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

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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

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.

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

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.

Hier ist meine Methode zur Behebung dieses Problems.

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

2. 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).

3. 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 !

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.

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.

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.

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.