Datei oder Assembly System.Net.Http, Version = 4.0.0.0 konnte mit ASP.NET (MVC 4) Web API OData Prerelease nicht geladen werden

81

Problem

Nach der Installation der Vorabversion des Microsoft ASP.NET-Web-API-OData-Pakets 5.0.0-rc1 tritt die folgende Ausnahme auf:

Datei oder Assembly 'System.Web.Http, Version = 4.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)

Mein MVC 4-Projekt ist brandneu und sehr klein, nichts Besonderes. Ich ziele auf .NET Framework 4.5

ich brauche das Nuget-Paket , um PATCH mithilfe der Delta-Klasse zu implementieren (wenn ich die Version 4.0.0.0 des Pakets verwende, funktioniert die Delta-Klasse nicht).

Wie kann ich das beheben?

Meine Versionen von System.Web.Http

In GAC habe ich Version 5.0.0.0 von System.Web.Http

gacutil -l System.Web.Http Der globale Assemblycache enthält die folgenden Assemblys: System.Web.Http, Version = 5.0.0.0, Kultur = neutral, PublicKeyToken = 31bf3856ad364e35, Prozessorarchitektur = MSIL

Wenn ich in Visual Studio Assemblys durchsuche, lautet die angegebene Version von System.Web.Http 4.0.0.0 (Warum?)

In meinem Projekt der Verweis auf System.Web.Http

  • Hat die Version 5.0.0.0
  • Zeigt auf den Ordner \ lib \ net45 \ des Pakets
  • Hat CopyLocal = true

Dinge, die ich versucht habe

Ich habe versucht, Redirect v 4.0.0.0 an 5.0.0.0 in Web.config zu binden

<dependentAssembly>
    <assemblyIdentity name="System.Web.Http" publicKeyToken="31bf3856ad364e35" culture="neutral" />
    <bindingRedirect oldVersion="4.0.0.0-4.0.0.0" newVersion="5.0.0.0" />
</dependentAssembly>

Aber es gibt mir eine andere Ausnahme:

Der Versuch der Methode 'System.Web.Http.GlobalConfiguration..cctor ()', auf das Feld 'System.Web.Http.GlobalConfiguration.CS $ <> 9__CachedAnonymousMethodDelegate2' zuzugreifen, ist fehlgeschlagen.

Ich denke, dass v 4.0.0.0 wirklich von der Web-API-Kern-Engine verwendet werden muss.

Verknüpfte Fragen

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

Yves M.
quelle
1
Vielleicht kann diese Antwort Ihnen helfen: stackoverflow.com/a/18700279/795876
fsenart

Antworten:

164

Visual Studio 2013 verfügt über eine neue Funktion, um dies zu beheben. Wenn Sie die App erstellen, sollten Warnungen zu verschiedenen Versionen einer Assembly angezeigt werden, auf die verwiesen wird. Doppelklicken Sie auf die Warnung, um der web.config Assembly-Bindungsumleitungen hinzuzufügen.

Siehe http://msdn.microsoft.com/en-us/library/2fc472t2.aspxWeitere Informationen finden .

jeff.eynon stellt unten fest, dass Sie die Datei web.config auschecken müssen (wenn Sie die TFS-Quellcodeverwaltung verwenden), damit VS die Datei automatisch bearbeitet. Danke für den Tipp!

Jay Douglass
quelle
7
Ich wünschte, ich könnte dies 10 Mal positiv bewerten. VS dies automatisch tun zu lassen war schön. Danke für den Tipp!
Bob Horn
4
Leider funktioniert es nicht immer. Tatsächlich würde ich oft sagen, dass ein Doppelklick auf diese Warnung nichts bewirkt.
Trevor de Koekkoek
3
Die Web- / App-Konfiguration, die geändert wird, muss ausgecheckt sein. Aus irgendeinem Grund scheint VS in diesem Fall nicht bereit zu sein, die Datei für Sie auszuchecken.
jeff.eynon
39

Ich habe es geschafft, indem ich das WebApi-Paket mit nuget auf die Vorabversion aktualisiert habe:

PM> Microsoft.AspNet.WebApi -Pre

Um das Projekt mit der neuesten Version von WebApi zu erzwingen, waren einige Änderungen an der Root-Datei Web.config erforderlich:

1) Webseitenversion von 2.0.0.0 bis 3.0.0.0

<appSettings>
    <add key="webpages:Version" value="3.0.0.0" />
</appSettings>

2) Bindungsumleitung zu 5.0.0.0 für System.Web.Http und System.Net.Http.Formatting

<dependentAssembly>
    <assemblyIdentity name="System.Web.Http" publicKeyToken="31bf3856ad364e35" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-5.0.0.0" newVersion="5.0.0.0" />
</dependentAssembly>
<dependentAssembly>
    <assemblyIdentity name="System.Net.Http.Formatting" publicKeyToken="31bf3856ad364e35" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-5.0.0.0" newVersion="5.0.0.0" />
</dependentAssembly>

Ich denke das ist es

PS: Lösung, die stark von WebAPI OData 5.0 Beta inspiriert ist - Der Zugriff auf GlobalConfiguration löst einen Sicherheitsfehler aus

Yves M.
quelle
3
Dies funktionierte für mich - ich hatte das gleiche Problem bei der Installation des neuesten CORS-Web-API-Pakets aufgrund der aktualisierten Abhängigkeit von system.net.http.
Sandeep Talabathula
1
Du rockst Mann, vielen Dank. In meinem Fall wurde die Webkonfiguration nicht durch die Nuget-Wiederherstellung aktualisiert. Ich habe dies nach der Bereitstellung manuell durchgeführt.
Leandro
Ebenso erhält dies eine +1, da Sie diese Antwort benötigen, wenn VS dies nicht für Sie erledigt, damit die Bindung selbst funktioniert.
Michael Blackburn
11

Ich bin auf dasselbe Problem gestoßen und habe es behoben, indem ich CopyLocal für die folgenden Bibliotheken auf true gesetzt habe:

System.Web.Http.dll
System.Web.Http.WebHost.dll
System.Net.Http.Formatting.dll

Ich muss hinzufügen, dass ich MVC4 und NET 4 verwende

Bronek
quelle
1
das hat es auch für mich gelöst - aber ich würde wirklich gerne wissen, was das eigentlich bedeutet?
Serup
11

Dieses Problem trat auf, als ich versuchte, ein Hot Towel-Projekt aus der Projektvorlage zu aktualisieren, und als ich ein leeres Projekt erstellte und HotTowel per Nuget in VS 2012 ab dem 23.10.2013 installierte.

Um dies zu beheben, habe ich über Nuget die Web-API-Webhost- und Web-API-Pakete auf 5.0 aktualisiert, die aktuelle Version in NuGet (23.10.2013).

Ich habe dann die Bindungsanweisungen hinzugefügt:

<dependentAssembly>
  <assemblyIdentity name="System.Web.Http" publicKeyToken="31bf3856ad364e35" culture="neutral" />
  <bindingRedirect oldVersion="0.0.0.0-5.0.0.0" newVersion="5.0.0.0" />
</dependentAssembly>
<dependentAssembly>
  <assemblyIdentity name="System.Net.Http.Formatting" publicKeyToken="31bf3856ad364e35" culture="neutral" />
  <bindingRedirect oldVersion="0.0.0.0-5.0.0.0" newVersion="5.0.0.0" />
</dependentAssembly>
Kevin LaBranche
quelle
8

Oder Sie können dies über die NuGet Package Manager-Konsole tun

 Install-Package Microsoft.AspNet.WebApi -Version 5.0.0

Anschließend können Sie den Verweis auf System.Web.Http.WebHost 5.0 hinzufügen

Sameer Alibhai
quelle
4

Entfernen Sie System.Web.Http und System.Net.Http.Formatting aus Ihren Referenzen und fügen Sie Referenzen wieder hinzu, indem Sie zu Ihrem bin-Ordner navigieren (in den sie von nuget kopiert wurden). In der Dateiversion heißt es nun 5.0.0.0

JJ_Coder4Hire
quelle
1

Dieser Fehler trat mehrmals bei verschiedenen Projekten auf.

Was ich schließlich herausgefunden habe, ist, dass sich beim Erstellen bereits eine Kopie der binären Assembly system.web.mvc in meinem Ordner bin befand.

Um dies zu beheben, klicken Sie mit der rechten Maustaste auf die Baugruppe in der Referenzliste und wählen Sie "Eigenschaften". Überprüfen Sie anhand der Eigenschaft "Version", ob dies die neueste Version ist. Wenn dies der Fall ist, schalten Sie "Copy Local" auf true.

Dadurch wird sichergestellt, dass die Version, auf die in Ihrem Projekt verwiesen wird, die Version ist, die in Ihrem Binärordner landet.

Wenn Sie immer noch den Fehler erhalten, versuchen Sie, nuGet auszuführen, um die neueste Version zu erhalten, und versuchen Sie es dann erneut.

Viel Glück - dieser Fehler ist ein Schmerz!

user1628627
quelle
1

Ich hatte den gleichen Fehler. Bei der Installation von Unity Framework for Dependency Injection wurden die neuen Referenzen von Http und HttpFormatter in meine Konfiguration aufgenommen. Hier sind die Schritte, denen ich gefolgt bin.

Ich habe den folgenden Befehl in der nuGet Package Manager-Konsole ausgeführt: PM> Install-Package Microsoft.ASPNet.WebAPI -pre

Und physische Referenz zur DLL mit Version 5.0 hinzugefügt

Chandra Prakash Soni
quelle
1

Ich löse übrigens Nuget. Das erste Mal installieren Sie Nuget. die Sekunde, die Sie verwenden.
Abbildung folgen:

Drittens: Überprüfen Sie anhand der Eigenschaft "Version", ob dies die neueste Version ist.

Das letzte: Sie überprüfen, ob das Projekt wieder die neueste Version hat.

Nguyễn Thị Nữ
quelle
0

Ich habe die gleiche Art von Problem festgestellt und die folgenden Schritte ausgeführt, um das Problem zu beheben

Gehen Sie zu Tools -> Library Package Manager -> Package Manager Console und führen Sie den folgenden Befehl aus

Installationspaket Microsoft.ASPNet.WebAPI -pre

Santu Ghosh
quelle
0

Nachdem Web.configwir die Referenzen in der Datei wie oben erwähnt geändert haben, haben wir die Referenzen aufgelöst.

Ich hatte ein ähnliches Problem.

Für uns haben wir Referenz Microsoft.Data.Edm.dllund OData.dllund andere Baugruppen aus Program Files:

C:\Program Files (x86)\Microsoft WCF Data Services\5.0
                          \bin\.NETFramework\Microsoft.Data.Edm.dll

und

C:\Program Files (x86)\Microsoft WCF Data Services\5.0
                        \bin\.NETFramework\Microsoft.Data.OData.dll

und Version war 5.6.4 .

Nachdem ich die Referenz beider Assemblys in geändert habe C:\....Project\packages\Microsoft.Data.Edm.5.6.0, wurde das Problem behoben

Gaurav Gupta
quelle
0

Ging in den Nuget Package Manager und aktualisierte meine Pakete. Jetzt gehts. Das wichtigste, das ich aktualisiert habe, war Microsoft.AspNet.WebApi.Core. Möglicherweise muss dies bei beiden Projekten durchgeführt werden, um die richtigen Referenzen zu synchronisieren.

Exzile
quelle
0

Wenn dieses Problem auftritt, überprüfen Sie bitte die Datei web.config im folgenden Abschnitt

Der folgende Abschnitt enthält die Version der verwendeten DLL

Nachdem Sie diesen Abschnitt in web.config überprüft haben, öffnen Sie den Lösungs-Explorer und wählen Sie wie gezeigt die Referenz aus dem Projektbaum aus. Projektmappen-Explorer-> Referenz

Suchen Sie nach dem Erweitern der Referenz die DLL, die den Fehler verursacht hat. Klicken Sie mit der rechten Maustaste auf die DLL-Referenz und suchen Sie nach der im obigen Bild gezeigten Version.

Wenn sowohl die Konfigurations-DLL-Version als auch die referenzierte DLL unterschiedlich sind, wird diese Ausnahme angezeigt. Stellen Sie sicher, dass beide dieselbe Version haben, was hilfreich wäre.

user3235808
quelle