Das manifest Definition befindet Assembly nicht den Montagebezug gefunden

https://stackoverflow.com/questions/215026

03-07-2019
|

Frage

Ich versuche, einige Unit-Tests in einem C # Windows Forms-Anwendung (Visual Studio 2005) zu laufen, und ich erhalte die folgende Fehlermeldung:

System.IO.FileLoadException: Konnte nicht geladen werden Datei oder Assembly 'Dienstprogramm, Version = 1.2.0.200, Culture = neutral, PublicKeyToken = 764d581291d764f7' oder eine ihrer Abhängigkeiten. Die manifest Definition befindet Assembly nicht die Montagereferenz entsprechen. (Ausnahme von HRESULT: 0x80131040) **

bei x.Foo.FooGO ()

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

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

System.IO.FileLoadException: Konnte nicht geladen werden Datei oder Assembly 'Dienstprogramm, Version = 1.2.0.203, Culture = neutral, PublicKeyToken = 764d581291d764f7' oder eine ihrer Abhängigkeiten. Die manifest Definition befindet Assembly nicht die Montagereferenz entsprechen. (Ausnahme von HRESULT: 0x80131040)

Ich sehe in meine Referenzen, und ich habe nur einen Verweis auf Utility version 1.2.0.203 (das andere ist alt).

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

Außerdem, ich glaube nicht einmal, ich auf meiner Festplatte diese alte Montage haben. Gibt es ein Werkzeug für diese alte versioniert Montag suchen?

Lösung

Der .NET Assembly Loader ist nicht in der Lage 1.2.0.203 zu finden, aber ein 1.2.0.200 gefunden hat. Diese Anordnung entspricht nicht, was angefordert wurde und man daher diesen Fehler. In einfachen Worten, es kann nicht die Versammlung findet, auf die verwiesen wurde. Stellen Sie sicher, dass es die richtige Montage finden sie im GAC oder im Applikationspfad, indem. Auch finden Sie unter http://blogs.msdn.com/junfeng/archive /2004/03/25/95826.aspx .

Andere Tipps

Sie können ein paar Dinge tun, um dieses Problem zu beheben. Verwenden Sie zuerst Suche Windows-Datei Ihre Festplatte für die Assembly (DLL) zu suchen. Sobald Sie eine Liste der Ergebnisse haben, tun View-> Details auswählen ... und überprüfen Sie dann „Version File“. Dies wird in der Liste der Ergebnisse, die die Versionsnummer angezeigt werden, so können Sie sehen, wo die alte Version von könnte kommen.

Auch, wie Lars sagte, überprüfen Sie Ihre GAC zu sehen, welche Version dort aufgeführt ist. diesem Microsoft-Artikel besagt, dass Assemblys im GAC gefunden nicht lokal während eines Build kopiert, so dass Sie die alte Version entfernen, müssen möglicherweise vor einer Wiederherstellung alles zu tun. (Siehe meine Antwort auf diese Frage für Notizen auf eine Batch-Datei erstellen zu tun das für Sie)

Wenn Sie immer noch nicht herausfinden, wo die alte Version herkommt, können Sie die Fuslogvw.exe Anwendung, die mit Visual Studio Weitere Informationen über die Bindung zu Fehlern kommen. Microsoft hat Informationen zu diesem Tool hier . Beachten Sie, dass Sie müssen die Protokollierung aktivieren, indem Sie den HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Fusion\EnableLog Registrierungsschlüssel auf 1 zu setzen.

Ich lief in dieses Problem mich, und ich fand, dass das Problem etwas anders war als das, was die anderen haben laufen in.

hatte ich zwei DLLs, die mein Hauptprojekt wurde Referenzierung: CompanyClasses.dll und CompanyControls.dll. Ich war ein Laufzeitfehler sagen immer:

konnte nicht geladen werden Datei oder Assembly ‚CompanyClasses, Version = 1.4.1.0, Culture = neutral, PublicKeyToken = 045746ba8544160c‘oder eine ihrer Abhängigkeiten. das liegt Assembly manifest Definition tut nicht die Montage Referenz entsprechen

Das Problem war, ich habe keine CompanyClasses.dll Dateien auf meinem System mit einer Versionsnummer von 1.4.1. Keiner im GAC, keine in den App-Ordner ... keine überall. Ich suchte meine gesamte Festplatte. Alle CompanyClasses.dll Dateien, die ich hatte, waren 1.4.2.

Das eigentliche Problem, fand ich, war, dass CompanyControls.dll Version verwiesen 1.4.1 von CompanyClasses.dll. Ich habe gerade CompanyControls.dll (nachdem es Referenz CompanyClasses.dll 1.4.2) neu übersetzt und dieser Fehler ging weg für mich.

In der folgenden Umleitungen jede Assemblierung-Version auf die Version 3.1.0.0. Wir haben ein Skript, das diese Referenz in der App.config immer aktualisiert werden, so müssen wir uns nie wieder mit diesem Thema befassen.

Durch Reflexion können Sie die Montage PublicKeyToken erhalten und erzeugen diesen Block aus der DLL-Datei selbst.

<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 ohne ein XML-Namespace-Attribut (xmlns), wird dies nicht funktionieren.

Wenn Sie Visual Studio verwenden, versuchen Sie „saubere Lösung“ und dann Projekt neu.

Die anderen Antworten wäre für mich nicht. Wenn Sie nicht über die Version ist es egal, und Sie wollen nur Ihre App dann mit der rechten klicken Sie auf den Verweis laufen und die spezifischen Version "auf false gesetzt ... Das funktionierte für mich. eingeben Bild Beschreibung hier

Ich lief gerade über dieses Problem und das Problem war ich eine alte Kopie der DLL in meiner Anwendung Debug-Verzeichnis hatte. Vielleicht haben Sie auch wollen, es zu überprüfen (anstelle des GAC), um zu sehen, wenn Sie es sehen.

Ich habe ein NuGet Paket, nur ein Black-Box-Teil meiner Anwendung zu realisieren, wurde Referenzierung eine ältere Version der Bibliothek.

entfernte ich das Paket und referenziert die statische DLL-Datei der älteren Version, 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, was sollte es rückgängig gemacht hat, wenn ich das Paket deinstalliert:

<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 während einer ASP.NET-Anwendung ausgeführt wird. Die Lösung war:

Löschen Sie die obj und bin Ordner im Projektordner

Sauber nicht funktioniert hat, wieder aufzubauen funktionierte nicht, alle Referenzen waren in Ordnung, aber es war nicht schriftlich eine der Bibliotheken. Nachdem diese Verzeichnisse zu löschen, funktionierte alles perfekt.

In meinem Fall war es eine alte Version der DLL in C: \ WINDOWS \ Microsoft.NET \ Framework \ ~ \ Temporary ASP.NET Files \ Verzeichnis. Sie können entweder löschen oder die alte Version ersetzen, oder Sie können den Verweis auf die DLL in Ihrem Projekt entfernen und wieder hinzufügen. Grundsätzlich wird entweder Weg, einen neuen Zeiger auf die temporären ASP.NET-Dateien erstellen.

Ich werde jeden Verstand im Augenblick der Luft zu sprengen. . .

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

Get-Project -All | Add-BindingRedirect

Für uns war das Problem durch etwas anderes verursacht. Die Lizenzdatei für die DevExpress Komponenten enthielt zwei Linien, eine für eine alte Version der Komponenten, die nicht auf diesem Computer installiert wurde. Entfernen Sie die ältere Version aus der Lizenzdatei löste das Problem.

Das lästige Teil ist, dass die Fehlermeldung keine Anzeichen gab, auf welche Referenz die Probleme verursacht wurde.

Diese exakt die gleichen Fehler, wenn Sie zu spät binden mit Reflexion versuchen geworfen, wenn die Assembly Sie benannten starken Bindung sind bekommt oder hat seine Public-Key-Token geändert. Der Fehler ist das gleiche, obwohl es nicht wirklich jede Baugruppe mit den angegebenen öffentlichen Schlüssel-Token gefunden wird.

Sie müssen den richtigen öffentlichen Schlüssel-Token hinzugefügt (Sie können es sn -T auf der DLL erhalten), um den Fehler zu beheben. Hoffe, das hilft.

Meins war eine sehr ähnliche Situation wie der Beitrag von Nathan Bedford, aber mit einer leichten Drehung. Mein Projekt auch die geänderte DLL auf zwei Arten verwiesen. 1) unmittelbar und 2) indirekt von einer Komponente (Klassenbibliothek Referenzierung), dass ich einen Verweis auf die veränderte dll hatte. Jetzt ist mein Visual Studio-Projekt für die Komponente (2) verwies die richtige Version des geändertenen dll. Allerdings ist die Versionsnummer des compnent selbst wurde nicht verändert. Und als Ergebnis der von der neuen Version des Projektes installiert werden konnte, dass die Komponente auf dem Client-Rechner ersetzen.

Endergebnis: Direkte Referenz (1) und indirekter Verweis (2) auf dem Client-Rechner auf verschiedene Versionen des geändertenen dll zeigt wurden. Auf meiner dev Maschine es funktionierte gut.

Auflösung: Entfernen Anwendung; Löschen Sie alle DLLS von Anwendungsordner; Re-install.Simple wie in meinem Fall.

Ich werde jemand Nutzen aus meiner Scher Dummheit lassen. Ich habe einige Abhängigkeiten zu einer völlig separaten Anwendung (lassen Sie sich dies App1 nennen). Die DLL aus dieser App1 gezogen in meine neue Anwendung (App2). Jedes Mal, wenn ich Updates in APP1, ich habe neue DLL erstellen und kopieren Sie sie in App2. Gut. . .Ich hätte genug von Kopieren und Einfügen zwischen zwei verschiedenen Versionen App1, so fügte ich einfach einen ‚NEW_‘ Präfix zu dem DLL.

Well. . . Ich vermute, dass der Build-Prozess den / bin-Ordner durchsucht und wenn es falsch, etwas nach oben übereinstimmt, ist es barfs mit der gleichen Fehlermeldung wie oben erwähnt. Ich löschte meine „new_“ Versionen und gebaut nur Dandy.

Meine Frage wurde Kopieren Quellcode auf eine neue Maschine, ohne eine der referenzierten Assemblys Überhol-.

Nichts, was ich den Fehler behoben hat, so in Eile, ich BIN-Verzeichnis ganz gestrichen. Umgebaut meine Quellcode, und es funktionierte fortan aus.

Ich mag nur hinzufügen, dass ich ein grundlegendes ASP.NET MVC 4 Projekt war die Schaffung und die hinzugefügt DotNetOpenAuth.AspNet über NuGet. Dies führte zu den gleichen Fehler, nachdem ich eine unpassende DLL-Datei für Microsoft.Web.WebPages.OAuth verwiesen wird.

Um es zu beheben, habe ich eine Update-Package und reinigte die Lösung für einen vollständigen Neuaufbau.

Das ist für mich gearbeitet und ist ein bisschen eine faule Art, aber die Zeit ist Geld :-P

Ich habe diesen Fehler beim Aufbau auf Team Foundation Server Build-Service. Es stellte sich heraus, dass ich mit NuGet mehrere Projekte in meiner Lösung mit verschiedenen Versionen derselben Bibliothek hinzugefügt hatte. Ich entfernte alle alten Versionen mit NuGet und fügte hinzu, die neue als Referenz für alle.

Team Foundation Server stellt alle DLL-Dateien in einem Verzeichnis, und es kann nur zu einem Zeitpunkt natürlich eine DLL-Datei eines bestimmten Namens sein.

Meine app.config enthält ein

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

für Npgsql. Irgendwie auf dem Computer des Benutzers, mein app.exe.config vermisst. Ich bin nicht sicher, ob es ein dummer Benutzer, Installateur Glitch war, oder wacked aus noch anti-Virus. Ersetzen der Datei löste das Problem.

Ich habe gerade einen anderen Grund, warum diese Fehler zu bekommen. Ich säuberte meinen GAC aus allen Versionen einer bestimmten Bibliothek und baute mein Projekt mit Bezug auf spezielle Version mit der ausführbaren Datei eingesetzt zusammen. Als ich das Projekt ausführen bekam ich diese Ausnahme für eine neuere Version der Bibliothek zu suchen.

Der Grund war Verlag Politik . Wenn ich Bibliothek Versionen von GAC deinstalliert habe ich vergessen, Verleger Politik Versammlungen als auch so statt der Verwendung meiner lokal bereitgestellten Assembly die Montage Lader Verleger zu deinstallieren Politik in GAC gefunden, die es gesagt für eine neuere Version zu suchen.

Für mich ist die Code-Coverage-Konfiguration in der "Local.testtesttings" Datei "verursacht" das Problem. Ich habe vergessen, die Dateien zu aktualisieren, die dort verwiesen wurde.

Just Inhalt Ihres Projekts Binärordner löschen und neu erstellen die Lösung mein Problem gelöst.

sauber und die Lösung wieder aufbauen könnte nicht alle DLL aus dem Ausgabeverzeichnis ersetzen.

, was ich vorschlagen, ist zu versuchen, den Ordner „bin“ Umbenennung in „oldbin“ oder „obj“ auf „oldobj“

und dann versuchen, Ihre silution wieder bauen.

Incase, wenn Sie mit einer dritten Partei DLL diejenigen, die Sie in neu erstellte „bin“ kopieren müssen oder „obj“ -Ordner nach erfolgreicher Build.

hoffen, dass diese für Sie arbeiten.

Löschen Sie manuell die alte Baugruppe aus Ordner und dann das Hinzufügen der Verweis auf die neuen Baugruppen helfen könnten.

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

Auf den ersten, wenn die Anwendung installiert wurde, dann hier waren die Leute verwendet Microsoft Enterprise Library 4.1 in der Anwendung.
In den vergangenen Wochen wurde meine Maschine formatiert und danach heute, wenn ich diese Anwendung gebaut dann gab es mir einen Fehler, dass Enterprise Library Baugruppe fehlt.
Dann installierte ich Microsoft Enterprise Library 5.0, die ich auf Google bekam als erster Sucheintrag.
Dann, wenn ich die Anwendung gebaut dann gab es mir die obigen Fehler das heißt die manifest Definition befindet Assembly nicht die Montagereferenz entspricht.
Nach viel von einer Sucharbeit & Analyse, fand ich, dass die Anwendung bezog 4.1.0.0 & die DLL im Ordner ist war die Version 5.0.0.0
Was ich tat, war dann installierte ich die Microsoft Enterprise Library 4.1.
entfernt die vorherige Referenz (5,0) & hinzugefügt, um die 4.0 Referenz.
Einbau die Anwendung und voila ... es hat funktioniert.

Hier ist meine Methode, um dieses Problem zu beheben.

Von der Ausnahmemeldung, erhält den Namen der „Problem“ Bibliothek und die „erwartete“ Versionsnummer.

Suchen alle Kopien dieses DLL in Ihrer Lösung der rechten Maustaste auf sie, und prüfen Sie, welche Version der DLL ist.

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

Suchen Sie nach der Versionsnummer, die in der Ausnahmemeldung in allen der gezeigt wurde CSPROJ Dateien in Ihrer Lösung. Ersetzen Sie diese Versionsnummer mit der tatsächlichen Anzahl der dll.

So, in diesem Beispiel, würde ich ersetzen diese ...

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

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 Baugruppen wollten eine andere Version der DotNetOpenAuth Bibliothek verwenden, und das wäre kein Problem sein. Weiterhin auf meinem lokalen Computer wurde ein 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 wurde mir klar, dass ich vergessen hatte, die neuen web.config auf den Produktionsserver kopieren / einsetzen. Also, wenn Sie die manuelle Art und Weise web.config der Bereitstellung haben, überprüfen Sie es aktualisiert wird. Wenn Sie ganz andere web.config für Produktionsserver haben, müssen Sie diese dependentAssembly Abschnitt synchron fusionieren nach NuGet verwendet wird.

Wenn Sie jemals einen Fehler wie „ Die befindet Assembly manifest Definition nicht die Montage Referenz entsprechen “, und wenn Sie über Projekt aktualisiert> Verwalten NuGet Pakete und Registerkarte Update in VS , versuchen Sie das erste, was Sie tun können, ist eine andere Version des Pakets installiert wird, nachdem Versionen von NuGet Galerie Seite Überprüfung und der folowing Befehl von Package Manager-Konsole ausgeführt wird:

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

Obwohl Antwort nicht direkt auf das Paket in Frage bezogen und es wurde Rückweg fragt, ist es eine Art von Generika, das nach wie vor relevant und hofft, dass es jemanden hilft.

erhielt ich diese Fehlermeldung aufgrund Referenzierung eine Baugruppe, die den gleichen Namen wie die Versammlung hatte ich aufbaute.

Das zusammengestellt, aber es überschrieben Anordnung, die die referenzierte Assembly mit den aktuellen Projekten -. So den Fehler verursacht

Um es zu beheben, änderte ich den Namen des Projekts, und die Montageeigenschaften verfügbar durch einen Rechtsklick auf das Projekt und wählen Sie ‚Eigenschaften‘.

Ihre Assembly in AssemblyInfo.cs-Datei verwenden, um eine feste Versionsnummer statt Angabe von *. Die * wird die Versionsnummer auf jeder Zusammenstellung ändern. Das war das Problem für diese Ausnahme in meinem Fall.

Lizenziert unter: CC-BY-SA mit Zuschreibung

Nicht verbunden mit StackOverflow