Datei oder Assembly 'System.Net.Http, Version = 2.0.0.0 in MVC4 Web API konnte nicht geladen werden

92

Ich habe ein komisches Problem.
Ich habe eine App mit MVC 4 und der neuen Web-API entwickelt, die lokal einwandfrei funktioniert. Ich habe MVC4 auf dem Server installiert und die App bereitgestellt. Jetzt bekomme ich folgenden Fehler:

Datei oder Assembly 'System.Net.Http, Version = 2.0.0.0, Culture = neutral, PublicKeyToken = 31bf3856ad364e35' oder eine ihrer Abhängigkeiten konnte nicht geladen werden. Die Manifestdefinition der gefundenen Assembly stimmt nicht mit der Assemblyreferenz überein. (Ausnahme von HRESULT: 0x80131040)

Beschreibung: Während der Ausführung der aktuellen Webanforderung ist eine nicht behandelte Ausnahme aufgetreten. Bitte überprüfen Sie den Stack-Trace, um weitere Informationen über den Fehler und dessen Ursprung zu erhalten

Komischerweise ist die Version von System.Net.Http, die ich lokal entweder in meinem Paketordner oder im Ordner ASP.NET MVC 4 \ Assemblies habe, 1.0.0.0. Ich habe den Verweis auf System.Net.Http tatsächlich aus meinem Projekt entfernt, erhalte aber immer noch die gleiche Meldung. Ich bin etwas verwirrt darüber, woher die Referenz 2.0.0.0 stammt und warum sie lokal funktioniert, aber nicht auf dem Server.

Betrachten der Nuget-Abhängigkeiten:

ASP.NET WEb API Core Libraries (Beta) hängen von System.Net.Http.Formatting ab.
Und System.Net.Http.Formatting hängt von System.Net.Http ab.
Ich denke, das ist, woher das kommt. Aber ich habe Version 2.0.20126.16343 dieses Pakets installiert, es ist nur so, dass die DLL im Inneren Version 1.0.0.0 hat

Vermisse ich etwas

AKTUALISIEREN:

Dies ist eine Unteranwendung einer anderen ASP.NET-App, die andere basiert jedoch weiterhin auf WebForms. Also wird etwas durcheinander gebracht. Aber wenn ich eine Bereinigung unter dem Assembly-Abschnitt in der web.config mache, finde ich die App selbst nicht mehr.

Remy
quelle
Haben Sie für dieses Projekt die Funktion "Bereitstellbare Abhängigkeiten hinzufügen" verwendet?
ChristiaanV
Nein, habe das nicht versucht. Aber ich habe alles frisch eingerichtet und jetzt funktioniert es ... Nicht wirklich befriedigend, aber ...
Remy
Ich habe dieses Problem jedes Mal, wenn ich meinen Computer neu starte und Visual Studio neu starte. Irgendwie ging es weg, wenn ich sauber mache und dann die Lösung neu aufbaue.
Frostshoxx

Antworten:

30

Ich hatte das gleiche Problem mit der Bereitstellung meiner App für Appharbor. Das Problem, dass .NET 4.5 noch nicht unterstützt wird. Was ich getan habe.

  1. Mein Projekt wurde auf das .NET 4.0-Profil umgestellt.
  2. Deinstalliertes Web API NuGet-Paket.
  3. NuGet-Paket für Web-API (Beta) erneut installiert.
  4. Es wurde überprüft, dass die .csproj-Datei für ALLE Assemblys enthält, auf die verwiesen wird. Daher wird sie immer aus dem Bin-Ordner anstelle von GAC übernommen.
Alexander Beletsky
quelle
1
Irgendwie hat mein Projekt angefangen zu funktionieren, aber ich habe keine Ahnung warum ... Ihr Ansatz scheint machbar.
Remy
alexanderb - wie wechsle ich zum .NET 4.0-Profil? In Visual Studio? Wo befindet sich der Ordner bin? Ist die .csproj-Datei die web.config-Datei? Thx
WhoAmI
114

Ich hatte den gleichen Fehler beim Bereitstellen der zuvor konvertierten Webanwendung (von .NET 4.5 auf 4.0) unter IIS 6.0.

Im Abschnitt web.config Laufzeit habe ich gefunden

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

was ich geändert habe

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

Jetzt funktioniert wie Charme.

Krzysztof
quelle
4
Sollten die Assemblys bei dieser Änderung weiterhin so eingestellt werden, dass sie lokal kopieren?
Rasmus Christensen
3
Das Problem für mich war, dass eines meiner Web Api NuGet-Pakete eine Abhängigkeit von System.Net.Http 2.0.0.0 hatte, aber meine Referenz war 2.1.10.0, die in meinen bin-Ordner ausgegeben wurde.
JustinMichaels
2
Das ist richtig (wie Justin Michaels sagte). Die Abhängigkeit bezieht sich auf 2.0.0.0, aber Ihre Assembly-Referenz bezieht sich auf 2.1.xx. Alles, was Sie zur Behebung dieses Problems benötigen, ist die Bindungsumleitung.
Tod Thomson
2
Dieser sollte als die richtige Antwort markiert werden. Ich denke, deshalb drängen alle anderen Benutzer auf diese Option. Danke, Krzysztof!
Blaise
3
Das Problem ist wahrscheinlich nicht der direkte Verweis auf System.Net.Http, sondern ein indirekter Verweis, der in einer der anderen Bibliotheken verwendet wird, auf die Sie verweisen. Aus diesem Grund kann dieses Problem durch Festlegen der lokalen Kopie im Allgemeinen nicht behoben werden.
Paul Keister
10

Meins arbeitete mit:

Beachten Sie die Umleitung von 1-4 auf 2.0

<dependentAssembly>
    <assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a"   culture="neutral"/>
    <bindingRedirect oldVersion="0.0.0.0-4.0.0.0" newVersion="2.0.0.0"/>
</dependentAssembly>
Clive
quelle
Ich habe so etwas gemacht, aber ich habe newVersion auf 4.0.0.0 aktualisiert und oldVersion als 0.0.0.0-2.0.0.0 verlassen
Veritoanimus
2

Im Ordner "Referenzen" Ihres Projekts sollte sich ein Verweis auf diese DLL befinden, und die Version sollte 2.0.0.0 sein. Stellen Sie sicher, dass dies auf Copy Local = true eingestellt ist. Stellen Sie dann sicher, dass es in den Bin-Ordner Ihrer Server-App gelangt.

Dies ist eine der Bibliotheken, die jetzt von Nuget verwaltet wird. Öffnen Sie also Nuget und stellen Sie sicher, dass alles auf dem neuesten Stand ist. Und in Ihrem Projektpaketverzeichnis sollte sich die Datei hier befinden: \packages\System.Net.Http.2.0.20126.16343\lib\net40

Sie können auch versuchen, eine neue MVC4-App zu erstellen und festzustellen, ob die Datei für diese App angezeigt wird.

GeekyMonkey
quelle
1
Eigentlich verwirrt mich das. Ich benutze Nuget und habe diesen Ordner. Aber wenn ich mir System.Net.Http anschaue, hat es Version 1.0.0.0
Remy
1
Genau so habe ich es behoben! Da hat alles vor Ort geklappt. Ich habe gerade mit der rechten Maustaste auf die Referenz geklickt und in den Eigenschaften Copy localauf true gesetzt , wodurch sie behoben wird! einfacher / besser als in web.config-Dateien herumzuspielen. Fügen Sie einfach die DLL zu Ihrem bin-Ordner hinzu.
JP Hellemons
2

In meinem Fall habe ich es viel einfacher behoben. Geben Sie einfach einen Hinweis auf den Verweis auf das Nuget-Paket:

     <Reference Include="System.Data.Entity" />
     <Reference Include="System.Net.Http, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a">
       <Private>True</Private>
+      <HintPath>..\..\packages\Microsoft.Net.Http.2.0.20710.0\lib\net40\System.Net.Http.dll</HintPath>
     </Reference>
     <Reference Include="System.Net.Http.WebRequest, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a">
       <Private>True</Private>
+      <HintPath>..\..\packages\Microsoft.Net.Http.2.0.20710.0\lib\net40\System.Net.Http.WebRequest.dll</HintPath>
     </Reference>
     <Reference Include="System.Numerics" />
     <Reference Include="System.Security" />
knocte
quelle
1

In meinem Fall habe ich über NuGet ungewollt eine Abhängigkeit zu System.Net.Http Version 2.1.10.0 hinzugefügt. Ich konnte es im NuGet Package Manager nicht loswerden (weil andere Pakete davon abhängig zu sein schienen). Diese Pakete sind jedoch nicht von dieser bestimmten Version abhängig. Folgendes habe ich getan, um es loszuwerden (Sie können stattdessen auch die NuGet-Konsole verwenden (mit dem Parameter –force):

  • Ändern Sie die Version von Microsoft.Net.Http in packages.config von 2.1.10.0 auf 2.0.0.0
  • Deinstallieren Sie das BCL Portability Pack in NuGet Package Manager
  • Abhängige Bibliotheken (System.Net.Http. * Mit Version 2.1.10.0) manuell entfernen
  • Fügen Sie einen Verweis auf System.Net.Http 2.0.0.0 hinzu
Dunken
quelle
1

In der Dateikonfiguration habe ich die abhängige Assembly gelöscht:

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

Jetzt funktioniert es gut.

StefanoM5
quelle
Um XML-Tags richtig anzuzeigen, formatieren Sie Ihren Text als Code. Fügen Sie dazu einfach vier Leerzeichen vor jeder Zeile hinzu.
Artemix
Tnx Artemix, das ist mein erster Kommentar;)
StefanoM5
1

Ich hatte dieses Problem auf einem Testserver (Windows 2008 R2), der angeblich "bereit" für die Bereitstellung war;)

Der Hinweis war, dass die Versionen von System.net zwischen meinem DEV-Computer und dem Bereitstellungsserver nicht übereinstimmten, wenn ich sie überprüfte.

Mit den folgenden Schritten behoben:

  1. Das eigenständige Installationsprogramm für .NET Framework 4.5 wurde HIER heruntergeladen

  2. Führen Sie das Installationsprogramm auf dem Bereitstellungscomputer aus

Nach der Installation des Frameworks wollte der Server einen Neustart, das auch und volla! Wir sind gut zu gehen !!

Sudhanshu Mishra
quelle
1

Wir verwenden VS 2013, haben eine neue MVC 4-Web-API erstellt und hatten ein Problem damit, dass system.net.http.dll nicht die richtige Version ist, wenn es auf unserem TeamCity-Server erstellt wird, aber es funktioniert einwandfrei auf unseren lokalen Entwicklercomputern mit VS 2013 Eingerichtet.

Wir haben endlich das Problem festgestellt.

Beim Erstellen einer neuen MVC 4-Web-API und Auswählen des Frameworks 4.0 bei der Projekterstellung wurde festgestellt, dass die richtige NuGet-Paketversion für die DLL eingegeben wurde: .. \ packages \ Microsoft.Net.Http.2.0.20710.0 \ lib \ net40 \ System.Net.Http.dll

In der .csproj-Datei für dieses Projekt heißt der Pfad für diese system.net.http.dll-Datei jedoch: .. \ packages \ Microsoft.Net.Http.2.0.30506.0 \ lib \ net40 \ System.Net.Http.dll

Wenn also versucht wird, einen Build zu erstellen, schlägt dieser Pfadunterschied fehl, findet jedoch die richtige Framework-Version der Datei an anderer Stelle auf dem Entwicklercomputer, jedoch nicht auf unserem TeamCity-Buildserver.

Bisher ist dies der einzige Unterschied, den wir gefunden haben. Das Ändern des Pfads in der .csproj-Datei und das Erstellen auf einem lokalen Dev-Computer mit VS2013 funktioniert weiterhin.

Wenn Sie dies in die Versionskontrolle einchecken und unseren TeamCity-Buildserver (ohne VS 2013 lokal installiert) haben, wird jetzt die richtige Version der DLL in ihrem NuGet-Paketordner für die Lösung gefunden und erfolgreich erstellt, anstatt nach einer anderen Version von system.net.http zu suchen .dll und Finden einer neueren Version, die nicht zum Framework passt, was zu Buildfehlern führt.

Ich bin mir nicht sicher, ob dies hilft.

Überprüfen Sie den Pfad Ihrer Projektdatei für die DLL und stellen Sie sicher, dass er mit dem Pfad Ihres Paketordners für die DLL übereinstimmt.

Eric Reiss
quelle
1

Ich vereinfache nur die anderen Antworten für das, was für mich funktioniert hat.

Ich ging zum NuGet-Manager, deinstallierte die zugehörigen Pakete (in meinem Fall "Microsoft ASP.NET Web API 2.1-Clientbibliotheken" und "Json.NET") und installierte sie erneut. Nur ein paar Klicks.

Rudy Scoggins
quelle
0

Schließen Sie das Projekt und öffnen Sie es erneut. Dann Clean Solution + Build. Funktioniert bei mir

Lücks
quelle
0

Für Version 2.2.15.0 habe ich Folgendes getan:

<dependentAssembly>
    <assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
    <bindingRedirect oldVersion="0.0.0.0-4.0.0.0" newVersion="2.2.15.0"/>
</dependentAssembly>
Osama
quelle
0

Ich hatte genau das gleiche Problem! Ich habe mir die Registerkarte Warnungen in VS angesehen und festgestellt, dass eines meiner Nuget-Pakete INDIREKT auf .NETFramework Version 4.5.0.0 verweist. Ich musste dieses Paket deinstallieren und dann die 4.0-Version neu installieren, aber stellen Sie sicher, dass Sie die Paketversionen angeben, die 4.0 unterstützen (ich glaube, es wird standardmäßig auf 4.5 zurückgesetzt, wenn Sie dies bei der Installation des Pakets nicht angeben). Hoffe das hilft!

Javier Gonzalez
quelle
0

Dies geschah nach der Bereitstellung auf einem Server. Es wurde entweder verursacht durch:

A) Alte Dateien im Bin-Ordner, die noch herumhängen, sollten gelöscht werden

oder

B) Kein Lesezugriff auf den Ordner für den Benutzer der Anwendungspoolidentität.

Mit anderen Worten, für uns wurde dies behoben, indem Berechtigungen für die Ordner für die Site festgelegt und der Ordner bin gelöscht und erneut bereitgestellt wurden.

Chris Moschini
quelle
0

Ich hatte das gleiche Problem mit Gembox.spreadsheet.dll Version 31.

"Datei oder Assembly 'GemBox.Spreadsheet, Version = 39.3.30.1095, Culture = neutral, PublicKeyToken = b1b72c69714d4847' 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 habe fast alles aus diesen Artikeln ausprobiert und keiner von ihnen hat funktioniert. Es wurde gerade mit einem einfachen Schritt behoben.

Ich habe versucht, einzelne Projekte zu erstellen, die im Grunde den richtigen Versionsverweis auf die DLL eingerichtet haben, und der Fehler war vollständig aus der Lösung verschwunden.

Rachana
quelle
0

Gehen Sie ein ähnliches Problem und die in vielen Kommentaren erwähnte Richtlinie hat gut funktioniert

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

Sie müssen jedoch sicherstellen, dass die Abdeckung der alten Version hoch genug ist, da sonst neuere Versionen möglicherweise nicht auf die von Ihnen benötigte Version umgeleitet werden und der Speicherort mit dieser neueren Referenz nicht ordnungsgemäß funktioniert, da sich die ältere Referenz bereits im bin-Verzeichnis befindet.

Micaël
quelle
0

Für diesen Fehler (und ähnliches) lohnt es sich, NuGet Consolidate (Lösung> NuGet-Pakete verwalten ...) durchzugehen, um sicherzustellen, dass in jeder Klassenbibliothek, auf die in der Lösung verwiesen wird, dieselben Komponentenversionen konsistent sind, da möglicherweise auch eine etwas ältere Version Abhängigkeiten aufweist auf anderen älteren Komponenten. Es ist unkompliziert in Verbindung mit Updates zu verwenden und kann viel Schmerz sparen.

Dies hat dieses Problem für mich gelöst und ich würde sagen, es ist ein Muss, sich damit vertraut zu machen, wenn Sie Hilfsbibliotheken erstellen, die auch auf MVC oder andere webbasierte NuGet-Komponenten verweisen.

mhapps
quelle