Datei oder Assembly System.Net.Http.Primitives konnte nicht geladen werden. Die Manifestdefinition der gefundenen Assembly stimmt nicht mit der Assemblyreferenz überein

68

Ich arbeite an einem Programm, das die Google-API verwendet. Jedes Mal, wenn ich mein Programm starte, wird der folgende Fehler angezeigt:

Datei oder Assembly 'System.Net.Http.Primitives, Version = 1.5.0.0, Culture = neutral, PublicKeyToken = b03f5f711d50a3a' oder eine ihrer Abhängigkeiten konnte nicht geladen werden. Die Manifestdefinition der gefundenen Assembly stimmt nicht mit der Assemblyreferenz überein.

Ich verwende Visual Studio 2012 Express. Ich habe versucht, diesem Link zu folgen und habe viele Foren durchgesehen, aber keines scheint zu funktionieren. Das Hauptproblem scheint von der DLL-Datei "Google.Apis.dll" zu stammen, auf die ich verwiesen habe, und sie verweist auf System.Net.Http.Primitives v1.5.0.0. Die Version, auf die mein Programm verweist, ist jedoch 2.2.13.0. Ich habe versucht, stattdessen die Programmreferenz v1.5.0.0 zu verwenden (ich finde die DLL zusammen mit dem Quellcode von Google.Apis), dies verursachte jedoch nur ein weiteres Problem, bei dem ich eine neuere Version von System.Net benötigte. Http.Primitives.

Ich habe versucht, einen Weg zu finden, um dies zu umgehen, aber ich kann anscheinend nichts finden, was funktioniert. Danke für die Zeit.

exception  google-api-dotnet-client 
— Tri
quelle
— Ken White
1
Hallo! Wo können Sie dieses Problem lösen? Ich habe das gleiche Problem. Vielen Dank!
— WhoAmI
Ich habe die gleiche Fehlermeldung für ein Web-API-Projekt erhalten, obwohl ich die Google-API nicht verwendet habe. Der Wiederaufbau des Projekts löste das Problem.
— Hong
7
Ein weiterer klarer Fall von Nuget DLL Hölle
— Ferran Salguero

Antworten:

71

Ich bin auf dasselbe Problem mit den Google-APIs gestoßen. Das Hauptproblem hierbei ist, wenn Sie die Microsoft Http Client Libraries installieren, die in Ihrem Projekt eine aktualisierte Version der System.Net.Http.Primitives DLL enthalten. In der web.config wird davon ausgegangen, dass Sie weiterhin die Standardversion von 1.5 verwenden. Es müssen zwei Dinge passieren, um das Problem zu beheben:

Erstens: Aktualisieren Sie auf die neuesten Versionen von Google API und Microsoft Http Client Libraries . Sie können die Updates über NuGet installieren. Klicken Sie mit der rechten Maustaste auf Ihre Website, klicken Sie auf "NuGet-Pakete verwalten" und wählen Sie links "Updates" aus. Zum Zeitpunkt dieses Beitrags sind einige der Google-APIs nur vorab verfügbar. Sie können sie über NuGet installieren, indem Sie oben links im Update-Bildschirm "Prerelease einschließen" auswählen.

Zweites Update / Hinzufügen einer abhängigen Baugruppe zu Ihrer web.config. Dazu müssen Sie die Version der installierten System.Net.HTTP.Primitives.dll kennen. Suchen Sie in Ihrem bin-Verzeichnis im Windows Explorer. Suchen Sie System.Net.HTTP.Primitives.dll, klicken Sie mit der rechten Maustaste darauf, wählen Sie Eigenschaften aus und klicken Sie auf die Registerkarte "Details". Beachten Sie die dort befindliche Version. Zum Zeitpunkt dieses Beitrags war meins 4.0.10.0 .

Fügen Sie dann einen abhängigen Assembly-Abschnitt für die richtige Version hinzu / aktualisieren Sie ihn. 

<runtime>
  <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
    <dependentAssembly>
      <assemblyIdentity name="System.Net.Http.Primitives" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
      <bindingRedirect oldVersion="0.0.0.0-4.0.10.0" newVersion="4.0.10.0"/>
    </dependentAssembly>
  </assemblyBinding>
</runtime>
— Paul Lemke
quelle
4
+1 Erster Schritt war genug, um das Problem für mich zu lösen
— CodingIntrigue
3
Nur um darauf hinzuweisen, dass die Http.Primitives-Version "2.2.22.0" ist und der Beispielcode "4.0.10.0" zeigt. Aber das ist die richtige Antwort, sollte akzeptiert werden
— Raphael Isidro
3
Der Sinn von Nuget besteht darin, keine manuelle Baugruppenbindung in der Web.Config zu erfordern. Ich vermisse die alte Google API bereits. Wenn ich jetzt meine Wrapper-DLL verteile, muss ich sie irgendwie benachrichtigen, damit sie Ihre beiden Schritte für jedes Projekt ausführen können, das sie verwenden möchte.
— DFTR
Vielen Dank! Dies hat einen Fehler behoben. "Die Methode 'MyMethod' vom Typ 'MyClass' aus der Assembly 'MyAssembly' hat keine Implementierung." Dies wurde nur beim Erben von einem Typ in Google.Apis.Auth.Mvc4.dll angezeigt. Ich musste lediglich die BindingRedirect bereits in meiner app.config in meine nunit-Konfigurationsdatei kopieren.
— David Hogue
Das Update mit Nuget (erster Schritt) hat das Problem auch für mich gelöst.
— Needfulthing
34

Was für mich funktioniert hat, war einfach die "Microsoft Http Client Libraries" von Nuget zu installieren.

— Senkwe
quelle
Welche Namespaces haben Sie nach der Installation verwendet? Thx
— WhoAmI
4
Dies funktionierte für mich, als ich es speziell zu meinem Testprojekt hinzufügte (wo ich auf das Problem gestoßen bin), unabhängig davon, dass es bereits im Hauptprojekt referenziert wurde, auf das wiederum von meinem Testprojekt verwiesen wurde.
— keithl8041
Und um dies zu tun, musste ich nuget.exe in unserer Lösung aktualisieren - seirer.net/blog/2014/5/20/…
— jaminto
1
— Installationspaket
Niether Microsoft.Net.Http- oder System.Net.Http-Nuget-Pakete enthalten die System.Net.Http.Primitives.dll. Ich bin mir nicht sicher, ob sie es in der Vergangenheit getan haben. Meine Suche geht weiter.
— Rob
5

Fügen Sie Ihrer web.config (app.config) Folgendes hinzu:

<runtime>
  <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
    <dependentAssembly>
      <assemblyIdentity name="System.Net.Http.Primitives" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
      <bindingRedirect oldVersion="0.0.0.0-4.2.13.0" newVersion="4.2.13.0"/>
    </dependentAssembly>
  </assemblyBinding>
</runtime>
— Aviw
quelle
Ich bin mir nicht sicher über Ihren altenVersionsbereichswert und Ihren neuenVersionswert. Mein neuerVersionswert ist: 2.2.29.0
— kstubs
4.2.29 für mich, Ziel .Net 4.5
— S. Baggy
In meinem Fall zeigte das erstellte Vesrion-Nuget auf 4.2.29, aber die Version, die ich auf meinem Computer hatte, war tatsächlich 4.2.13 (GAC_MSIL \ System.Net.Http.Primitives) ... als ich die Umleitung auf 4.2.13 änderte, es fing an zu arbeiten! Ich bin mir nicht sicher, warum es passiert ist, aber wenn jemand alle Arten von Problemumgehungen versucht und es immer noch nicht zum Laufen bringt, lohnt es sich, in Ihrem GAC nachzusehen, welche Version Sie tatsächlich haben.
— eeee
3

Bei mir hat es folgendes geklappt:

In Visual Studio (2012)> Tools> Nuget Package Manager> Package Manager-Konsole. Über der Paket-Manager-Konsole befindet sich die Paketquelle: nuget.org Standardprojekt: Das Projekt, für das System.Net.Http.Primitives erforderlich ist. In der Projektdatei (yourproject.csproj) mit einem Editor beobachten, welche Version benötigt wird (in mein Fall war Microsoft.Net.Http.2.2.28)

Also ging ich zu https://www.nuget.org/packages/Microsoft.Net.Http/ und klickte unter "Versionsverlauf" auf meine Version (scrollen Sie ein wenig auf der Seite, wenn Sie sie nicht sehen). Nachdem Sie die Version ausgewählt haben, kopieren Sie den vorgeschlagenen Befehl - in meinem Fall war es:

Installationspaket Microsoft.Net.Http -Version 2.2.28

Wenn Sie jedoch die neueste Version benötigen, ist dies genau das Folgende:

Installationspaket Microsoft.Net.Http

und Sie fügen es in Ihre Visual Studio Package Manager-Konsole ein, die zuvor wie zuvor beschrieben geöffnet wurde. Führen Sie den Befehl aus.

Im Projekt unter den Referenzen wird System.Net.Http.Primitives jetzt aktualisiert.

— Daniele D.
quelle
2

Ich hatte ein ähnliches Problem.

Versuchen Sie, Nuget zu aktualisieren (Tools / Erweiterungen und Updates ...). Das und einige andere Probleme wurden für mich behoben.

/ Jonas

— JoBe
quelle
2

Wir hatten das ähnliche Problem. Aber in meinem Fall hat die Lösung, die app.config von Paul zu ändern, nicht funktioniert. Der Grund ist, dass ich es als Plugin in einer anderen Anwendung verwende. Daher wird die Konfigurationsdatei dieser Anwendung berücksichtigt. Also haben wir den Google API-Code von GitHub erhalten und die Google.Apis.Core-Bibliothek erstellt, nachdem wir die Abhängigkeit von System.Net.Http.Primitives entfernt haben. Dann haben wir diese DLL verwendet, die unser Problem gelöst hat.

— Ashish
quelle
2

Dieses Problem trat auf, als ich meinen Code, der Google.Apis.Drive.v2 (v1.9.2.1860) verwendet, für das Unternehmen veröffentlichte, für das ich arbeite. Ich habe ihnen die Exe und alle DLLs gegeben, die Visual Studio (und NuGet) generiert haben, und sie haben den Fehler erhalten. Ich habe den Fehler nie bekommen.

Das Update war einfach (nachdem ich es herausgefunden hatte): Bei der Installation der API von Nuget wird die Datei 'assemblyname.exe.config' automatisch im Ausgabeordner (auch bekannt als Debug oder Release) generiert. Alles, was Sie tun müssen, ist, diese Datei einzuschließen, wenn Sie die Assembly an einem anderen Ort als dem Ordner ausführen, für den sie generiert wurde. Hier ist der Code für diese Datei für mich:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
    <startup> 
        <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.5" />
    </startup>
  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="System.Net.Http.Primitives" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-4.2.29.0" newVersion="4.2.29.0" />
      </dependentAssembly>
    </assemblyBinding>
  </runtime>
</configuration>

Dies ist im Grunde Pauls "zweiter" Fix, der jedoch automatisch vom Paketmanager generiert wird. Das Problem für mich war, als ich versuchte, sein "erstes" Update durch Aktualisierung auf Google.Apis.Auth und Google.Apis.Core (v1.9.3) durchzuführen, was die Sache noch schlimmer machte. Ich würde den gleichen Fehler erhalten, außer dass jetzt "Google.Apis.Core" die falsche Version war (obwohl dies wahrscheinlich auch durch Einfügen derselben .exe.config-Datei hätte behoben werden können.)

Ich hoffe, das hilft jemandem. Ich weiß, dass dieser Thread ziemlich alt ist, aber es ist derjenige, zu dem mich eine schnelle Google-Suche geführt hat.

Bearbeiten: Ich habe vergessen zu erwähnen, dass dies für eine Konsolenanwendung relevant ist, die auf .NET 4.5 abzielt. Einiges davon ist wahrscheinlich noch für andere .NET-Ziele oder ASP.NET relevant, aber ich weiß es nicht genau. Ihr Kilometerstand kann variieren.

— Andrew Roth
quelle
Tut mir leid, das zu stoßen, aber das war tatsächlich die einzige Lösung für mich. Es wird erklärt, warum es im Debug-Map / Debug-Modus und nicht im freigegebenen Ordner ausgeführt wird. Gibt es eine Möglichkeit, dies zu verhindern? Dort werden viele Informationen angezeigt, die leicht zugänglich sind und auf die normale Benutzer nicht einfach zugreifen können.
— Kevin G
1

Die obige Antwort zur Baugruppenbindung ist korrekt, Sie sollten jedoch NICHT die Datei machine.config berühren.

Die Assemblybindung muss in der Konfigurationsdatei aller EXECUTABLE-Assemblys Ihres Projekts (.exe.config) festgelegt werden, die auf Ihre Bibliothek verweisen, und nicht in den Bibliotheksassemblys (.dll.config).

— Echtelion
quelle
0

Irgendwie hat die beliebte Antwort von Paul Lemke bei mir nicht funktioniert. Das Projekt ist eine Webforms-Anwendung, die mit .net v 2.0 gestartet und auf .net Version 4.5 aktualisiert wurde

Ich habe die Pakete aktualisiert und Nuget hat die richtigen abhängigen Assembly / BindingRedirects erstellt.

Nach einigen Kommentaren ist es wahrscheinlich nicht die beste Idee, die lokale Datei machine.config zu ändern.

Anscheinend hatte ich ein Attribut in meiner web.config-Datei, das dazu führte, dass die App die BindingRedirects ignorierte.

<configuration xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0">

Ich habe dieses xmlns-Attribut entfernt und es hat funktioniert.

— Vincejtl
quelle
0

Konnte dies ziemlich leicht lösen. Öffnen Sie einfach den Nuget Package Manager und aktualisieren Sie das Microsoft ASP.NET Web API 2.2-Clientbibliothekspaket. Dadurch wurde Microsoft.Net.Http auf die neueste Version aktualisiert, wodurch das Problem behoben wurde, dass die System.Net.Http.Primitives-Assembly nicht gefunden werden konnte. Hoffe das hilft!

— R007
quelle
0

In meinem Fall habe ich auf die NuGet-Pakete aus einer Klassenbibliothek verwiesen. NuGet informiert uns nicht darüber, dass die app.config der Klassenbibliothek vollständig ignoriert wird und wir ihren Inhalt manuell in die app.config der EXE-Datei kopieren müssen.

— DBN
quelle
Wo finden Sie die Bibliothek app.config? Haben Sie den gesamten Inhalt kopiert?
— Dakab
Es befindet sich normalerweise im Stammverzeichnis des Projektordners und wird bin\Foo.dll.configbeim Kompilieren in kopiert . Sie sind im XML-Format, so dass man sie normalerweise nicht einfach wörtlich kopieren kann. Sie müssen verglichen und die fehlenden Teile einzeln kopiert werden.
— DBN
0

NuGet hat die folgende Änderung in Web.Config vorgenommen

<dependentAssembly> <assemblyIdentity name="System.Net.Http.Primitives" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" /> <bindingRedirect oldVersion="0.0.0.0-4.2.22.0" newVersion="4.2.22.0" /> </dependentAssembly>

zu

<dependentAssembly> <assemblyIdentity name="System.Net.Http.Primitives" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" /> <bindingRedirect oldVersion="0.0.0.0-4.2.28.0" newVersion="4.2.28.0" /> </dependentAssembly>

Dies erfolgte nach der Installation und dem anschließenden Entfernen (durch Zurücksetzen der Versionskontrolle) dieses Pakets https://www.nuget.org/packages/Microsoft.AspNet.WebApi.MessageHandlers.Compression/

— gb2d
quelle
0

Ich hatte ein ähnliches Problem mit PowerShell-Skripten für TFS 2017. Die Skripte wurden als .NET-Code bezeichnet, um benutzerdefinierte Aktionen während der Erstellungsprozesse auszuführen. Ich bekam immer wieder Fehler über DLL-Versionskonflikte.

Ich konnte das Problem nicht beheben, bis ich einen Hook in das AppDomain AssemblyResolve-Ereignis implementiert habe, wie in der folgenden Antwort beschrieben: Binden von Weiterleitungen für Office-Add-Ins

Diese Lösung zwang den Prozess, DLLs aus dem aktuellen Pfad zu verwenden. Ich weiß, dass dies ein Hack ist, aber ich hatte gelesen, dass Sie beim Ausführen von PowerShell nicht immer Bindungsumleitungen verwenden können, was ich ursprünglich versucht hatte: https://github.com/google/google-api-dotnet -client / issue / 555

— Mr.Zzyzzx
quelle
0

Installationspaket Microsoft.Net.Http -Version 2.2.22

Diese Version hat die DLL \ packages \ Microsoft.Net.Http.2.2.22 \ lib \ net45 \ System.Net.Http.Extensions.dll

— user2540680
quelle
-2

In meinem Fall fügt Nuget automatisch Folgendes zu web.config hinzu

<runtime xmlns="">
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
  <dependentAssembly>
    <assemblyIdentity name="System.Threading.Tasks" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-2.6.9.0" newVersion="2.6.9.0" />
  </dependentAssembly>
  <dependentAssembly>
    <assemblyIdentity name="System.Runtime" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-2.6.9.0" newVersion="2.6.9.0" />
  </dependentAssembly>
  <dependentAssembly>
    <assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-2.2.22.0" newVersion="2.2.22.0" />
  </dependentAssembly>
  <dependentAssembly>
    <assemblyIdentity name="System.Net.Http.Primitives" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-2.1.10.0" newVersion="2.1.10.0" />
  </dependentAssembly>
</assemblyBinding>

Aber ich habe immer noch die obige Fehlermeldung erhalten, schließlich finde ich es heraus. Sie müssen diese Tags in die machine.config kopieren Datei sich unter C: \ Windows \ Microsoft.NET \ Framework64 \ v4.0.30319 \ Config \ machine.config befindet.

Um das Tag "runtime" auf machine.config zu finden, ersetzen oder fügen Sie es (falls es kein solches Tag gibt) durch Ihre Tags aus Ihrer web.config (die oben aufgeführten) hinzu.

— Fliegenpferd1999
quelle
@ flyhorse1999, ungefähr ein Jahr zu spät, aber probieren Sie die Lösung, die ich gepostet habe. Meine Anwendung hat die BindingRedirects aufgrund eines Attributs, das ich entfernen musste, nicht abgehört.
— Vincejtl
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.