Die Manifestdefinition der gefundenen Baugruppe stimmt nicht mit der Baugruppenreferenz überein

Question

Ich versuche, einige Unit-Tests in einer C# Windows Forms-Anwendung (Visual Studio 2005) auszuführen, und ich erhalte den folgenden Fehler:

System.IO.FileLoadException: Die 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 dem Assemblyverweis überein. (Ausnahme von HRESULT: 0x80131040)**

at x.Foo.FooGO()

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

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

System.IO.FileLoadException: Die 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 dem Assemblyverweis überein. (Ausnahme von HRESULT: 0x80131040)

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

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

Außerdem glaube ich nicht, dass ich diese alte Baugruppe noch auf meiner Festplatte habe. Gibt es ein Werkzeug, mit dem man nach dieser alten Version der Baugruppe suchen kann?

Answer 1

Der .NET Assembly Lader:

• kann 1.2.0.203 nicht finden
• aber ich habe eine 1.2.0.200 gefunden

Diese Baugruppe stimmt nicht mit dem überein, was angefordert wurde, und deshalb erhalten Sie diesen Fehler.

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

Answer 2

Es gibt mehrere Möglichkeiten, dieses Problem zu beheben. Verwenden Sie zunächst die Windows-Dateisuche, um auf Ihrer Festplatte nach Ihrer Assembly (.dll) zu suchen. Sobald Sie eine Liste der Ergebnisse haben, wählen Sie Ansicht->Details wählen... und aktivieren Sie dann "Dateiversion". Dadurch wird die Versionsnummer in der Ergebnisliste angezeigt, so dass Sie sehen können, woher die alte Version stammen könnte.

Prüfen Sie außerdem, wie Lars sagte, Ihre GAC, um zu sehen, welche Version dort aufgeführt ist. Dieser Microsoft-Artikel besagt, dass Assemblies, die im GAC gefunden werden, während eines Builds nicht lokal kopiert werden, so dass Sie möglicherweise die alte Version entfernen müssen, bevor Sie einen Rebuild durchführen. (Siehe meine Antwort auf diese Frage für Hinweise zur Erstellung einer Batch-Datei, die dies für Sie erledigt)

Wenn Sie immer noch nicht herausfinden können, woher die alte Version kommt, können Sie die Anwendung fuslogvw.exe verwenden, die mit Visual Studio geliefert wird, um weitere Informationen über die Bindungsfehler zu erhalten. Microsoft bietet Informationen zu diesem Tool aquí . Beachten Sie, dass Sie die Protokollierung aktivieren müssen, indem Sie die Option HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Fusion\EnableLog Registry-Schlüssel auf 1.

Answer 3

Ich bin gerade selbst auf dieses Problem gestoßen und habe festgestellt, dass es sich um etwas anderes handelt als das, was die anderen festgestellt haben.

Ich hatte zwei DLLs, auf die mein Hauptprojekt verwiesen hat: CompanyClasses.dll und CompanyControls.dll. Ich bekam einen Laufzeitfehler, der besagte:

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

Das Problem war, dass ich keine CompanyClasses.dll-Dateien mit einer Versionsnummer von 1.4.1 auf meinem System hatte. Keine im GAC, keine in den Anwendungsordnern... 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 die Version 1.4.1 von CompanyClasses.dll verwies. Ich habe CompanyControls.dll einfach neu kompiliert (nachdem ich CompanyClasses.dll 1.4.2 referenziert hatte) und der Fehler war weg.

Answer 4

Ich werde jetzt alle in den Wahnsinn treiben

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

Answer 5

Das Folgende leitet jede Assembly-Version auf Version 3.1.0.0 um. Wir haben ein Skript, das diese Referenz in der App.config immer aktualisiert, so dass wir uns nie wieder mit diesem Problem befassen müssen.

Durch Reflexion können Sie die Assembly publicKeyToken erhalten 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 funktionieren wird.