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

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.

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.

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.

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>

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.

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" />

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

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.

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

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.

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.

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

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>

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!

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.

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.

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.

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.