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.
Antworten:
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.
quelle
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
was ich geändert habe
Jetzt funktioniert wie Charme.
quelle
Meins arbeitete mit:
Beachten Sie die Umleitung von 1-4 auf 2.0
quelle
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.
quelle
Copy local
auf 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.In meinem Fall habe ich es viel einfacher behoben. Geben Sie einfach einen Hinweis auf den Verweis auf das Nuget-Paket:
quelle
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):
quelle
In der Dateikonfiguration habe ich die abhängige Assembly gelöscht:
Jetzt funktioniert es gut.
quelle
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:
Das eigenständige Installationsprogramm für .NET Framework 4.5 wurde HIER heruntergeladen
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 !!
quelle
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.
quelle
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.
quelle
Schließen Sie das Projekt und öffnen Sie es erneut. Dann Clean Solution + Build. Funktioniert bei mir
quelle
Für Version 2.2.15.0 habe ich Folgendes getan:
quelle
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!
quelle
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.
quelle
Ich hatte das gleiche Problem mit Gembox.spreadsheet.dll Version 31.
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.
quelle
Gehen Sie ein ähnliches Problem und die in vielen Kommentaren erwähnte Richtlinie hat gut funktioniert
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.
quelle
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.
quelle