it-swarm.com.de

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 ich erhalte die folgende Fehlermeldung:

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

bei x.Foo.FooGO ()

um 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-Dienstprogramm konnte nicht geladen werden, Version = 1.2.0.203, Culture = neutral, PublicKeyToken = 764d581291d764f7 'oder eine ihrer Abhängigkeiten. Die Manifestdefinition der gefundenen Assembly stimmt nicht mit der Assemblyreferenz überein. (Ausnahme von HRESULT: 0x80131040)

Ich schaue in meinen Referenzen nach und habe nur einen Hinweis auf Utility version 1.2.0.203 (der andere ist alt).

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

Ich glaube auch nicht, dass ich diese alte Assembly auf meiner Festplatte habe ... Gibt es ein Werkzeug, um nach dieser alten versionierten Assembly zu suchen?

631
leora

Der .NET Assembly Loader kann 1.2.0.203 nicht finden, aber 1.2.0.200. Diese Assembly stimmt nicht mit der Anforderung überein und daher wird dieser Fehler angezeigt. In einfachen Worten kann die Assembly, auf die verwiesen wurde, nicht gefunden werden. Stellen Sie sicher, dass die richtige Baugruppe gefunden wird, indem Sie sie in die GAC oder in den Anwendungspfad stellen. Siehe auch http://blogs.msdn.com/junfeng/archive/2004/03/25/95826.aspx .

403
Lars Truijens

Sie können dieses Problem mit einer Reihe von Maßnahmen 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-> Wählen Sie Details aus und markieren Sie "Dateiversion". Dadurch wird die Versionsnummer in der Ergebnisliste angezeigt, sodass Sie sehen können, woher die alte Version stammt.

Wie Lars sagte, überprüfen Sie auch Ihre GAC, um zu sehen, welche Version dort aufgeführt ist. Dieser Microsoft-Artikel besagt, 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 alles neu erstellen. (Siehe meine Antwort auf diese Frage für Hinweise zum Erstellen einer Batchdatei, um dies für Sie zu erledigen.)

Wenn Sie immer noch nicht wissen, woher die alte Version stammt, können Sie die im Lieferumfang von Visual Studio enthaltene fuslogvw.exe-Anwendung 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 Registrierungsschlüssel HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Fusion\EnableLog auf 1 setzen.

87

Ich bin einfach selbst auf dieses Problem gestoßen und habe festgestellt, dass das Problem etwas anderes war als das, was die anderen gemacht haben.

Ich hatte zwei DLLs, auf die sich mein Hauptprojekt bezog: CompanyClasses.dll und CompanyControls.dll. Ich habe einen Laufzeitfehler erhalten, in dem es heißt:

Datei oder Assembly konnte nicht geladen werden 'CompanyClasses, Version = 1.4.1.0, Kultur = neutral, PublicKeyToken = 045746ba8544160c 'oder eine seiner Abhängigkeiten. Die gefundenen Die Manifestdefinition der Assembly tut dies stimmt nicht mit der Assembly-Referenz überein

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

Ich fand heraus, dass das eigentliche Problem darin bestand, 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 weggegangen.

53
Nathan Bedford

Im Folgenden werden alle Assembly-Versionen auf Version 3.1.0.0 umgeleitet. Wir haben ein Skript, das diese Referenz in App.config immer aktualisiert, so dass wir uns nie wieder mit diesem Problem befassen müssen.

Durch Nachdenken können Sie das 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.

45
Yaniv.H

Wenn Sie Visual Studio verwenden, versuchen Sie "Clean Solution" und erstellen Sie Ihr Projekt neu.

38
Tad

Die anderen Antworten würden für mich nicht funktionieren. Wenn Sie sich nicht für die Version interessieren und einfach 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 für mich funktioniert.enter image description here

32
RayLoveless

Ich stieß gerade auf dieses Problem und das Problem war, dass ich eine alte Kopie der .dll in meinem Anwendungsdebug-Verzeichnis hatte. Möglicherweise möchten Sie auch dort (anstelle des GAC) nachsehen, ob Sie es sehen.

21
Neal Tibrewala

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

Ich habe das Paket entfernt und auf die statische Datei DLL der älteren Version verwiesen. Die Datei web.config wurde jedoch 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>

worauf hätte es bei der Deinstallation des Pakets zurückgreifen sollen:

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

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

14
Glade Mellor

In meinem Fall ist dieser Fehler beim Ausführen einer ASP.NET-Anwendung aufgetreten. Die Lösung lautete:

  1. Löschen Sie die Ordner obj und bin im Projektordner

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

14
Levi Fuller

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 Computer installiert war. Durch das Entfernen der älteren Version aus der Lizenzdatei wurde das Problem behoben. 

Das Ärgerliche daran ist, dass die Fehlermeldung keinen Hinweis darauf gab, welche Referenz die Probleme verursacht hat.

8
Sire

Meine Situation war der Situation von Nathan Bedford sehr ähnlich, jedoch mit einer leichten Drehung. Auch mein Projekt bezog sich auf zwei Arten auf die geänderte DLL. 1) Direkt und 2) Indirekt durch Referenzieren einer Komponente (Klassenbibliothek), die selbst einen Verweis auf die geänderte DLL hat. Jetzt verwies mein Visual Studio-Projekt für die Komponente (2) auf die korrekte Version der geänderten DLL. Die Versionsnummer der Komponente selbst wurde jedoch NICHT geändert. Daher konnte die Installation der neuen Version des Projekts diese Komponente auf dem Client-Computer nicht ersetzen.

Endergebnis: Direkter Verweis (1) und Indirekter Verweis (2) verweisen 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. Installieren Sie erneut. Einfach so wie in meinem Fall.

5
Bijimon

Der gleiche Fehler wird ausgegeben, wenn Sie versuchen, mithilfe der Reflektion zu spät zu binden, wenn die Assembly, an die Sie binden, einen starken Namen erhält oder der Token für den öffentlichen Schlüssel geändert wird. Der Fehler ist derselbe, obwohl mit dem angegebenen öffentlichen Schlüsseltoken tatsächlich keine Assembly gefunden wurde.

Sie müssen den richtigen öffentlichen Schlüsseltoken hinzufügen (Sie können ihn mithilfe von sn -T in der DLL erhalten), um den Fehler zu beheben. Hoffe das hilft.

5
Guy Starbuck

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 auf eine nicht übereinstimmende Datei DLL für Microsoft.Web.WebPages.OAuth verwiesen wurde.

Um das Problem zu beheben, habe ich einen Update-Package erstellt und die Lösung für einen vollständigen Umbau gereinigt.

Das hat für mich funktioniert und ist irgendwie faul, aber Zeit ist Geld :-P

4
Ben Pretorius

Mein Problem bestand darin, Quellcode auf eine neue Maschine zu kopieren, ohne die referenzierten Assemblys zu überschreiben. 

Ich habe den Fehler nicht behoben, also habe ich das BIN-Verzeichnis in aller Eile gelöscht. Erneuerte meinen Quellcode und es funktionierte von da an.

4

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

Gut. . . Ich vermute, dass der Build-Prozess den Ordner/bin durchsucht, und wenn er etwas falsch findet, wird er mit der gleichen Fehlermeldung angezeigt, wie oben angegeben. Ich habe meine "new_" -Versionen gelöscht und es wurde einfach Dandy gebaut.

4
Mike Murphy

Ich habe diesen Fehler erhalten, als ich den Build-Service von Team Foundation Server aufbaute. Es stellte sich heraus, dass ich mehrere Projekte in meiner Lösung hatte, bei denen verschiedene Versionen derselben Bibliothek 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 speichert alle DLL -Dateien in einem Verzeichnis, und zu einem Zeitpunkt kann natürlich nur eine DLL -Datei mit einem bestimmten Namen vorhanden sein.

4
cederlof

Meine app.config enthält eine

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

für npgsql. Irgendwie auf dem Rechner des Benutzers ging meine app.exe.config verloren. Ich bin mir nicht sicher, ob es sich um einen dummen Benutzer, um einen Installateur-Fehler oder um ein Virenschutzprogramm handelt. Durch das Ersetzen der Datei wurde das Problem behoben.

4
Thomas

Ich habe gerade einen anderen Grund gefunden, warum ich diesen Fehler erhalten sollte. Ich habe mein GAC aus allen Versionen einer bestimmten Bibliothek entfernt und mein Projekt mit Bezug auf eine bestimmte Version erstellt, die zusammen mit der ausführbaren Datei bereitgestellt wird. Beim Ausführen des Projekts erhielt ich diese Ausnahme, als ich nach einer neueren Version der Bibliothek suchte.

Der Grund war Publisher Policy . Als ich die Bibliotheksversionen von GAC deinstalliert habe, habe ich vergessen, auch Publisher-Richtlinienassemblys zu deinstallieren. Anstatt die lokal bereitgestellte Assembly zu verwenden, fand das Assembly-Ladeprogramm in GAC eine Publisher-Richtlinie, in der nach einer neueren Version gesucht wurde. 

3
Ladislav Mrnka

Die Code-Coverage-Konfiguration in der Datei "Local.testtesttings" hat das Problem verursacht. Ich habe vergessen, die dort referenzierten Dateien zu aktualisieren.

3
uli78

Wenn Sie einfach den Inhalt des Ordner-Ordners Ihres Projekts löschen und die Lösung neu erstellen, wurde mein Problem gelöst. 

2
dhiraj1mumbai

wenn Sie die Lösung bereinigen und neu erstellen, werden möglicherweise nicht alle DLLs aus dem Ausgabeverzeichnis ersetzt. 

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

und dann versuchen Sie es erneut. 

falls Sie eine Drittanbieter-DLL verwenden, müssen Sie sie nach dem erfolgreichen Erstellen in den neu erstellten Ordner "bin" oder "obj" kopieren.

ich hoffe, das wird für Sie funktionieren.

2
Ganesh Londhe

Es kann hilfreich sein, die alte Baugruppe manuell aus dem Ordner zu löschen und dann den Verweis auf neue Baugruppen hinzuzufügen.

1
rjain

In meinem Fall lag 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 automatisch von NuGet 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 merkte ich, dass ich vergessen hatte, die neue web.config auf den Produktionsserver zu kopieren/bereitzustellen. Wenn Sie die web.config-Methode auch manuell bereitstellen können, überprüfen Sie, ob sie aktualisiert wurde. Wenn Sie für den Produktionsserver eine komplett andere web.config-Datei haben, müssen Sie diese abhängigenAssemblys nach der Verwendung von NuGet synchronisieren.

1
Tomas Kubes

Ich habe den gleichen Fehler ... In meinem Fall wurde es wie folgt gelöst:

  • Zuerst, als die Anwendung installiert wurde, hatten die Leute hier Microsoft Enterprise Library 4.1 in der Anwendung verwendet.
  • In der vergangenen Woche war mein Computer formatiert. Danach habe ich beim Erstellen dieser Anwendung einen Fehler festgestellt, der darauf hinweist, dass die Enterprise Library Assembly fehlt.
  • Dann habe ich Microsoft Enterprise Library 5.0 installiert, die ich als ersten Sucheintrag bei Google bekam. 
  • Wenn ich dann die Anwendung erstellte, gab es den obigen Fehler, d. H. Die Manifestdefinition der lokalisierten Assembly stimmt nicht mit der Assemblyreferenz überein.
  • Nach langem Suchen und Analysieren stellte ich fest, dass die Anwendung auf 4.1.0.0 verwies. Die DLL im Ordner bin war Version 5.0.0.0
  • Ich habe dann die Microsoft Enterprise Library 4.1 installiert.
  • Die vorherige Referenz (5.0) wurde entfernt und die 4.0-Referenz hinzugefügt.
  • Bau der Anwendung und voila ... es hat funktioniert.
1
user4846550

Hier ist meine Methode, dieses Problem zu beheben.

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

 enter image description here

  1. Suchen Sie alle Kopien dieser .dll in Ihrer Projektmappe, klicken Sie mit der rechten Maustaste darauf und prüfen Sie, welche Version der .dll vorhanden ist.

 enter image description here

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

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

In diesem Beispiel würde ich das 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 !

1
Mike Gledhill

Das gleiche Problem hatte ich beim Ausführen meiner Gerätetestfälle.

Der Fehler besagt eindeutig das Problem: Wenn wir versuchen, Assembly zu laden, versucht das .NET Assembly-Ladeprogramm, die referenzierten Assemblys basierend auf ihren Manifest-Daten zu laden (referenzierter Assemblyname, öffentliches Schlüsseltoken, Version).

So prüfen Sie die Manifestdaten:

  1. Öffnen Sie die Eingabeaufforderung von Visual Studio.
  2. Geben Sie 'ildasm' ein, und ziehen Sie die gewünschte Assembly in das ILDASM-Fenster. Öffnen Sie die MANIFEST-Ansicht. In manchen Fällen enthält MANIFEST eine Assembly mit zwei Versionen der alten sowie der neuen Version (wie Utility, Version=1.2.0.200 und Utility, Version=1.2.0.203). In der Realität ist die angegebene Assembly zwar Utility, Version=1.2.0.203(new version), aber da das Manifest sogar Utility, Version=1.2.0.200(old version) enthält, versucht der .NET Assembly Loader, diese versionierte DLL -Datei herauszufinden, kann jedoch keine Ausnahme finden.

Ziehen Sie dazu einfach jede der projektabhängigen Assemblys in das ILDASM-Fenster und prüfen Sie, welche abhängige Assembly die Manifest-Daten mit der alten Assembly-Version enthält. Erstellen Sie einfach diese abhängige Assembly neu und verweisen Sie auf Ihr Projekt.

0
shan

Ich hatte heute das gleiche Problem, das mich daran hinderte, Add-Migration auszuführen, nachdem ich Änderungen in Entity Framework vorgenommen hatte. 

Ich hatte zwei Projekte in meiner Lösung, nennen wir sie "Client" und "Data" - ein Klassenbibliothek-Projekt, das meine EF-Modelle und den Kontext enthielt. Der Client verwies auf das Datenprojekt.

Ich hatte beide Projekte unterschrieben und später an einem EF-Modell Änderungen vorgenommen. Nachdem ich die Signatur entfernt hatte, konnte ich die Migrationen hinzufügen und das Projekt dann erneut signieren.

Ich hoffe, dass dies für jemanden nützlich sein kann, um ihn vor längerer Frustration zu bewahren.

0

Das Problem bei mir war, dass es alte DLLs gab, die in einem neuen Build gelöscht wurden. Um das Problem zu beheben, habe ich nur das Kontrollkästchen aktiviert, um beim Veröffentlichen zusätzliche Dateien am Ziel zu entfernen. Zusätzliche Dateien am Ziel entfernen

0
Bellatorius

Ich habe diese Fehlermeldung erhalten, weil ich auf eine Assembly verwiesen habe, die denselben Namen wie die Assembly hatte, die ich gerade baute. 

Dieses kompilierte aber überschrieb die referenzierte Assembly mit der aktuellen Assembly - und verursachte den Fehler.

Um das Problem zu beheben, änderte ich den Namen des Projekts und die verfügbaren Assembly-Eigenschaften, indem Sie mit der rechten Maustaste auf das Projekt klicken und "Eigenschaften" auswählen.

0
dan

Dieses Problem hatte ich, nachdem ich InstallShield verwendet hatte. Obwohl der Installationsauftrag das letzte Installationsprojekt anzeigte, wurde es nicht mehr gebaut.

Ich habe dies korrigiert, indem ich jedes andere Projekt davon abhängig machte - dies zwang die Installation, zuletzt zu bauen, und beseitigte damit meine fehlenden Baugruppen. Ich hoffe das hilft.

0
Tim

Ich werde jetzt alle umhauen. . .

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

Get-Project -All | Add-BindingRedirect
0
codeMonkey

Der gleiche Fehler tauchte für mich in meinem Unit-Tests-Projekt auf und führte zu einigen fehlgeschlagenen Tests. Ich überprüfte, welche Version der Assembly ich im Assembly Explorer verwendete, prüfte den Inhalt der Laufzeit-/abhängigen Assembly-Tags und stellte fest, dass eine andere Version der Assembly, die ich verwendet hatte, dort noch referenziert wurde. Da dies die einzige Direktive in meinem Testprojekt app.config war, habe ich einfach versucht, die gesamte app.config-Datei zu löschen, die Lösung neu zu erstellen, und das hat den Trick! Keine Referenzfehler mehr für mich :)

0
Ryan

Für mich hat keine Lösung funktioniert. Ich habe versucht, eine saubere Projektlösung zu erstellen, den Papierkorb 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 von geändert:

<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 gesäubert, es wieder aufgebaut und es hat funktioniert. Keine Warnung kein Problem.

0
Mi1anovic

OK, noch eine Antwort. Ich habe meine App zuvor als 64-Bit erstellt und den Ausgabepfad (Projekt/Eigenschaften/Build/Ausgabe/Ausgabepfad) entsprechend geändert. Kürzlich habe ich die App auf 32 Bit (x86) geändert und einen neuen Ausgabepfad erstellt. Ich habe eine Verknüpfung erstellt, zu der ich dachte , dass die kompilierte .exe gehen würde. Egal, was ich an der Quelle geändert habe, es wurde das Manifest nicht übereinstimmend Fehler. Nach ungefähr einer Stunde Frustration überprüfte ich zufällig das Datum und die Uhrzeit der EXE-Datei und stellte fest, dass sie alt war und offensichtlich auf alte DLL-Dateien verwies. Ich habe die App in das alte Verzeichnis kompiliert und meine Verknüpfung verwies auf das neuere. Der Ausgabepfad wurde dahin geändert, wo die .exe sollte los, rannte die Verknüpfung und der Fehler ist weg. (Ohrfeigen)

0
OldDog

Ich bekam:

Datei oder Assembly 'XXX-new' oder eine ihrer Abhängigkeiten konnte nicht geladen werden. Die Manifestdefinition der lokalisierten Assembly stimmt nicht mit der Assemblyreferenz überein. (Ausnahme von HRESULT: 0x80131040)

Das lag daran, dass ich den Namen der Assembly von XXX.dll in XXX-new.dll geändert habe. Das Zurücksetzen des Namens auf das Original behebt den Fehler.

0
mimo

check die licenses.licx in den Eigenschaften des Projekts du wirst dort die falsche Version finden .... es hat bei mir in aktiven Report-Aktualisierungen geklappt

0

Verwenden Sie in Ihrer AssemblyVersion in AssemblyInfo.cs-Datei eine feste Versionsnummer, anstatt * anzugeben. Das * ändert die Versionsnummer bei jeder Zusammenstellung. Das war das Problem für diese Ausnahme in meinem Fall.

0
DevXP

Die Frage hat bereits eine Antwort, aber wenn das Problem mit dem NuGet-Paket in verschiedenen Versionen in derselben Lösung aufgetreten ist, können Sie Folgendes versuchen.

Öffnen Sie den NuGet Package Manager, da sich meine Serviceprojektversion von anderen unterscheidet.

Aktualisieren Sie dann Projekte, die eine alte Version Ihres Pakets enthalten.

 Enter image description here

0
erhan355

Bitte lesen Sie die "vollständigen Details" in Visual Studio. Im Detail wurde mir mitgeteilt, dass eines meiner Projekte (das sich auf mein Hauptprojekt bezog) eine andere Version von Microsoft.IdentityModel.Clients.ActiveDirectory aufweist. In meinem Fall hat mein Unit-Test-Projekt mein Projekt aufgerufen. Mein Unit-Test-Projekt und mein Projekt haben eine andere Version von Microsoft.IdentityModel.Clients.ActiveDirectory. Ich erhalte einen Laufzeitfehler, als mein Komponententest ausgeführt wurde.

Ich habe gerade die Version meines Komponententestprojekts mit der gleichen Version des Hauptprojekts aktualisiert. Es hat bei mir funktioniert.

0
Vikrant

Wenn Sie eine Fehlermeldung erhalten, wie "Die Manifestdefinition der gefundenen Assembly stimmt nicht mit der Assemblyreferenz überein", und wenn Sie die Aktualisierung über Project> Registerkarte "NuGet-Pakete verwalten und aktualisieren" in VS vorgenommen haben, könnten Sie dies als erstes tun Versuchen Sie, eine andere Version des Pakets zu installieren, nachdem Sie die Versionen von Seite der NuGet-Galerie überprüft und den folgenden Befehl in der Package Manager Console ausgeführt haben:

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

Die Antwort bezieht sich zwar nicht direkt auf das fragliche Paket und wurde vor einiger Zeit gefragt, aber sie ist generisch, immer noch relevant und hofft, dass sie jemandem hilft.

0
Jaggan_j

Beim Versuch, eine DLL -Datei meiner Website zu aktualisieren, trat ein ähnliches Problem auf.

Dieser Fehler trat auf, als ich diese DLL -Datei einfach über FTP in den bin-Ordner kopierte.

Ich habe dieses Problem gelöst durch:

  1. stoppen der Website;
  2. kopieren der benötigten DLL Datei/DLL-Dateien;
  3. starten der Website
0
magicmanam

Hatte ein ähnliches Problem in diesem Beitrag erwähnt "Gibt es Vorschläge, wie ich herausfinden kann, was versucht wird, auf diese alte Version dieser DLL -Datei zu verweisen?"

Benötigt, welche Assembly noch den alten ODATA-Client 6.15.0 referenziert, half mir der Iildasm bei der Einschränkung (ohne Basiscode-Zugriff, nur über bereitgestelltes pkg am Server).

Screenshot unten für eine schnelle Zusammenfassung.

DeveloperPackge, wenn ildasm.exe nicht vorhanden ist https://www.Microsoft.com/net/download/visual-studio-sdks

 ildasm usage to resolve Assembly mismatch issue

0
Nara

Dies kann auch auftreten, wenn Sie AssemblyInfo.cs mit den AssemblyVersion-Tags verwenden und Ihre .csproj-Datei einen anderen Wert hat. Durch Abgleichen der AssemblyInfo oder Entfernen des gesamten Abschnitts wird das Problem behoben.

0
netniV

Ist mir passiert wegen System.ValueTuple

Unerwarteter Fehler Datei oder Assembly 'System.ValueTuple, Version = 4.0.1.0, Culture = neutral, PublicKeyToken = cc7b13ffcd2ddd51' oder eine ihrer Abhängigkeiten konnte nicht geladen werden. Die angegebene Datei wurde vom System nicht gefunden.

Es wurde behoben, indem .NET Framework 4.7.2 Runtime auf dem Computer installiert wurde, auf dem der Fehler aufgetreten ist. Einfach und ohne bindingRedirect hinzuzufügen, GAC zu ändern oder NuGet-Pakete herunterzustufen usw.

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

0
Ogglas

Ich bin auf dieses Problem gestoßen, als ich ein internes Paket-Repository verwendete. Ich hatte das Hauptpaket zum internen Repository hinzugefügt, nicht jedoch die Abhängigkeiten des Pakets. Stellen Sie sicher, dass Sie alle Abhängigkeiten, Abhängigkeiten von Abhängigkeiten, rekursiven usw. auch zu Ihrem internen Repository hinzufügen.

0
ScubaSteve