it-swarm.com.de

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. Nun bekomme ich folgende Fehlermeldung:

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. Überprüfen Sie die Stack-Ablaufverfolgung auf weitere Informationen zu dem Fehler und dem Ursprung des Fehlers

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

Betrachtung der Nuget-Abhängigkeiten:

ASP.NET WEb API-Kernbibliotheken (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 darin Version 1.0.0.0 hat 

Fehlt mir etwas?

UPDATE:

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

91
Remy

Ich hatte das gleiche Problem mit der Bereitstellung meiner App in AppHarbor. Das Problem unterstützt .NET 4.5 noch nicht. Was ich getan habe.

  1. Mein Projekt auf .NET 4.0-Profil umgestellt.
  2. Deinstalliertes Web-API-NuGet-Paket.
  3. Installiertes Web-API (Beta) NuGet-Paket erneut.
  4. Verifiziert, dass die .csproj-Datei ALLE referenzierten Assemblys enthält. Daher wird sie immer aus dem Ordner "Bin" anstelle von "GAC" genommen.
30

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

In der web.configruntimeSektion 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>

Funktioniert jetzt wie charmant.

111
Krzysztof

Meins arbeitete mit:

Beachten Sie die Weiterleitung 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>
10
Clive

In meinem Fall habe ich es viel einfacher behoben, geben Sie einfach einen 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" />
2
knocte

Im Ordner "Referenzen" Ihres Projekts sollte ein Verweis auf diese DLL vorhanden sein, und die Version sollte 2.0.0.0 sein. Stellen Sie sicher, dass hier Copy Local = true eingestellt ist. Stellen Sie dann sicher, dass der Weg zum Bin-Ordner Ihrer Server-App erfolgt.

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. Die Datei sollte sich in Ihrem Projektpaketverzeichnis befinden: \packages\System.Net.Http.2.0.20126.16343\lib\net40

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

2
GeekyMonkey

Einfach die anderen Antworten für das, was für mich funktionierte, vereinfachen.

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 neu. Nur ein paar Klicks gemacht.

1
Rudy Scoggins

Ich war mit diesem Problem auf einem Testserver (Windows 2008 R2) konfrontiert, 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.

Mit den folgenden Schritten behoben:

  1. Das .NET Framework 4.5 Standalone-Installationsprogramm wurde von HIER heruntergeladen.

  2. Führen Sie das Installationsprogramm auf der Bereitstellungsmaschine aus

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

1

In der Datei config 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.

1
StefanoM5

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

  • Ä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
  • Entfernen Sie manuell abhängige Bibliotheken (System.Net.Http. * Mit Version 2.1.10.0).
  • Fügen Sie einen Verweis auf System.Net.Http 2.0.0.0 hinzu
1
Dunken

Wir verwenden VS 2013, erstellten eine neue MVC 4-Web-API und hatten ein Problem mit der Version system.net.http.dll, die nicht die korrekte Version war, wenn sie auf unserem TeamCity-Server erstellt wurde. Auf unseren lokalen Entwicklercomputern mit VS 2013 ist dies jedoch problemlos möglich Eingerichtet.

Wir haben endlich das Problem festgestellt.

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

Die .csproj-Datei für dieses Projekt sagte jedoch, der Pfad für diese Datei system.net.http.dll lautet: ..\packages\Microsoft.Net.Http.2.0.30506.0\lib\net40\System.Net.Http .dll

Wenn also der Build-Versuch unternommen wird, schlägt dieser Pfadunterschied fehl, es wird jedoch an anderer Stelle auf dem Entwicklercomputer die richtige Framework-Version der Datei gefunden, jedoch nicht auf unserem TeamCity-Build-Server.

Bisher ist dies der einzige Unterschied, den wir gefunden haben. Das Ändern des Pfads in der .csproj-Datei und das Erstellen auf lokaler Dev-Maschine mit VS2013 funktioniert immer noch.

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

Nicht sicher, ob das hilft.

Überprüfen Sie den Projektdateipfad auf DLL und stellen Sie sicher, dass er dem Paketordnerpfad für die DLL entspricht.

1
Eric Reiss

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

"Datei oder Assembly 'GemBox.Spreadsheet, Version = 39.3.30.1095, Kultur = neutral, PublicKeyToken = b1b72c69714d4847' oder eine ihrer Abhängigkeiten konnte nicht geladen werden Assembly Referenz. (Ausnahme von HRESULT: 0x80131040) "

Ich habe fast alles aus diesen Artikeln ausprobiert und keiner hat funktioniert. Es wurde gerade mit einem einfachen Schritt behoben. 

Ich habe versucht, einzelne Projekte zu erstellen, die im Grunde die korrekte Versionsreferenz für die DLL einrichten, und der Fehler ist vollständig aus der Lösung verschwunden.

0
Rachana

Bei diesem Fehler (und ähnlichem) sollten Sie NuGet Consolidate (Solution> Manage NuGet Packages ...) verwenden, um sicherzustellen, dass in jeder Klassenbibliothek, auf die in der Lösung verwiesen wird, die gleichen referenzierten Komponentenversionen konsistent sind, da selbst eine etwas ältere Version Abhängigkeiten aufweisen kann bei anderen älteren Komponenten. Es ist unkompliziert in Verbindung mit Updates zu verwenden und kann eine Menge Schmerz ersparen.

Dies löste dieses Problem für mich und ich würde sagen, es ist ein Muss, wenn Sie Helfer-Bibliotheken erstellen, die ebenfalls auf MVC oder andere webbasierte NuGet-Komponenten verweisen.

0
mhapps

Ich hatte genau dieselbe Ausgabe! Ich habe mir die Registerkarte "Warnungen" in VS angesehen und festgestellt, dass eines meiner Nuget-Pakete UNBEDINGT auf .NETFramework Version 4.5.0.0 verweist. Ich musste dieses Paket deinstallieren und dann die 4.0-Version erneut installieren. Geben Sie jedoch die Paketversionen an, die 4.0 unterstützen (es wird standardmäßig auf 4.5 zurückgesetzt. Ich glaube, wenn Sie das Paket nicht installieren). Hoffe das hilft!

0
Javier Gonzalez

Wir hatten dies nach der Bereitstellung auf einem Server. Es wurde entweder verursacht durch:

A) Alte Dateien im Ordner bin noch vorhanden, die gelöscht werden sollten

oder

B) Sie haben keinen Lesezugriff auf den Ordner für den Benutzer des Application Pool Identity.

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

0
Chris Moschini

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>
0
Osama

Gehen Sie auf eine ähnliche Frage 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 ausreichend hoch ist. Andernfalls werden neuere Versionen möglicherweise nicht auf die von Ihnen benötigte Version umgeleitet, und der Speicherort mit dieser neueren Referenz funktioniert nicht ordnungsgemäß, da sich die ältere Referenz bereits im Verzeichnis bin befindet.

0
Micaël

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

0
Lücks