Datei oder Assembly "System.Net.Http, Version = 4.0.0.0, Kultur = neutral, PublicKeyToken = b03f5f7f11d50a3a" konnte nicht geladen werden.

165

Ich habe mein Projekt auf einen sauberen Windows 10-Computer kopiert, auf dem nur Visual Studio 2015 Community und SQL Server 2016 Express installiert sind. Außer den mit Windows 10 und VS2015 oder SQL Server installierten Framework-Versionen sind keine anderen Framework-Versionen installiert.

Wenn ich versuche, das WebApi-Projekt zu starten, wird folgende Meldung angezeigt:

Datei oder Assembly "System.Net.Http, Version = 4.0.0.0, Culture = neutral, PublicKeyToken = b03f5f7f11d50a3a" oder eine ihrer Abhängigkeiten konnte nicht geladen werden. Die angegebene Datei wurde vom System nicht gefunden.

Die Pakete des Projekts umfassen:

<package id="Microsoft.AspNet.WebApi" version="5.2.3" targetFramework="net45" />
<package id="Microsoft.AspNet.WebApi.Client" version="5.2.3" targetFramework="net45" />
<package id="Microsoft.AspNet.WebApi.Core" version="5.2.3" targetFramework="net45" />
<package id="Microsoft.AspNet.WebApi.Tracing" version="5.2.3" targetFramework="net45" />
<package id="Microsoft.AspNet.WebApi.WebHost" version="5.2.3" targetFramework="net45" />

Nach dem Erstellen des Projekts mit .NET Framework 4.6.1 wird System.Net.Httpdie Datei nicht im binOrdner gefunden.

Der Pfad der Datei zeigt auf:

C: \ Programme (x86) \ Referenzassemblies \ Microsoft \ Framework.NETFramework \ v4.6.1 \ System.Net.Http.dll

Der Pfad der Datei System.Net.Http.Formattingzeigt auf:

C: \ Development \ MyApp \ packages \ Microsoft.AspNet.WebApi.Client.5.2.3 \ lib \ net45 \ System.Net.Http.Formatting.dll

Sollte das gesamte Projekt auf 4.5.1 abzielen oder gibt es eine andere Möglichkeit, auf die richtigen Baugruppen zu verweisen?

Ivan-Mark Debono
quelle
Haben Sie versucht, Web Api aus dem NuGet-Paket neu zu installieren?
Mihai Alexandru-Ionut
Versuchte alle vorgeschlagenen Antworten in dieser SO-Frage. Bisher funktioniert nichts. Ich habe auch update-package xxx -reinstallfür alle Nuget-Pakete ausgeführt, die ich verwende. Es funktioniert auch nicht.
Ivan-Mark Debono
Verweisen Sie einfach darauf, danke mir später stackoverflow.com/questions/50536842/…
Ragul

Antworten:

112

Befolgen Sie die folgenden Schritte:

  1. Aktualisiere Visual Studio auf die neueste Version (es ist wichtig)
  2. Entfernen Sie alle verbindlichen Weiterleitungen von web.config
  3. Fügen Sie dies der .csprojDatei hinzu:

    <PropertyGroup>
      <AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects>
      <GenerateBindingRedirectsOutputType>true</GenerateBindingRedirectsOutputType>
    </PropertyGroup>
  4. Erstellen Sie das Projekt
  5. In dem binOrdner sollte sich eine (WebAppName).dll.configDatei befinden
  6. Es sollte Weiterleitungen enthalten, kopieren Sie diese in die web.config
  7. Entfernen Sie das oben genannte aus der .csprojDatei

Es sollte funktionieren

Sajeetharan
quelle
1
Jetzt wird die Datei oder Assembly 'Newtonsoft.Json, Version = 6.0.0.0, Culture = neutral, PublicKeyToken = 30ad4fe6b2a6aeed' oder eine ihrer Abhängigkeiten nicht geladen. Die Manifestdefinition der gefundenen Assembly stimmt nicht mit der Assemblyreferenz überein. (Ausnahme von HRESULT: 0x80131040)
EK_AllDay
2
Sie müssen daran denken, die Bindungsumleitungen aus der generierten Datei zu kopieren. Wenn Sie also zum ersten Mal den obigen Fehler erhalten, aber in den Ordner bin wechseln, um die generierte (webappname) .dll.config wie oben beschrieben zu erhalten, kopieren Sie die gesamte Liste der Weiterleitungen in Ihre web.config, dann neu kompilieren. Dies hat mir wirklich geholfen. Stellen Sie sicher, dass Sie das Nuget-Konsolidierungstool verwenden, um so viele Referenzen wie möglich zu bereinigen.
Chris Schaller
4
Tolle. Das hat bei mir tatsächlich funktioniert. @EK_AllDay Sie müssen die AssemblyRedirects zurück in die ursprüngliche web.config kopieren.
David De Sloovere
3
⭐☝ Legendenabzeichen hier verdient! Nur eine Randnotiz: Wenn ich die AssemblyRedirects zurück in web.config kopiere, sehe ich, dass für System.Net.Http keine Bindung mehr besteht . Wir gehen also davon aus, dass VS jetzt die Standardassembly verwendet, die im .NET-Framework enthalten ist, und nicht mehr die eigene Version.
EvilDr
1
Diese Antwort hat mich so oft gerettet, dass ich sogar aufgehört habe zu zählen. Sollte meiner Meinung nach als Antwort markiert sein.
Sebastian Budka
258

Ändern der Bindungsinformationen in meiner web.config (oder app.config) - während ein "Hack" in meiner Ansicht es Ihnen ermöglicht, mit Ihrem Projekt fortzufahren, nachdem ein NuGet-Paket-Update Ihre Anwendung durcheinander gebracht und Ihnen das System.Net.Http gegeben hat Error.

Setze newVersion = "4.0.0.0"

<dependentAssembly>
    <assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-4.1.1.0" newVersion="4.0.0.0" />
</dependentAssembly>
tripletdad99
quelle
4
Ich habe einmal ohne Probleme in Azure bereitgestellt, dann 15 Minuten später. Eine aufeinanderfolgende Bereitstellung gab mir den genauen Fehler, der im OP angegeben wurde, und das Optimieren der web.config auf dem Server mit dieser genauen Antwort behebt mein Problem. Aber ich habe keine Ahnung, warum es jemals beim ersten Mal funktioniert hat. Ich habe mich nicht mit meinen Abhängigkeiten zwischen Bereitstellungen herumgeschlagen.
bkwdesign
8
Gut gemacht. Ich kann sehen, was passiert ist. Ich habe ein Paket in einem Basisdomänenprojekt installiert, bei dem ich mir ziemlich sicher bin, dass das System.Net.Http-Nuget installiert ist (wahrscheinlich der höheren Version 4.1.x), und sobald ich das getan habe, habe ich diese erhalten Warnungen überall. Dies behebt das Problem für das Webprojekt, aber der obige Rat von jemandem, in allen Projekten auf das Nuget-Paket zu verweisen, entfernte alle Warnungen. Bin ich der einzige, der sich Sorgen um die Mischung aus altem und neuem .NET macht, wenn es um Referenzen geht? Es macht mir Angst, typische lokale DLLs als Nuget-Pakete (DLL-Hölle) zu bezeichnen.
Nicholas Petersen
3
Hier ist eine Antwort von Microsoft, warum dies der richtige Weg ist: github.com/dotnet/corefx/issues/25773
ghanashyaml
18
Das Entfernen der Bindungsumleitung hat bei mir vollständig funktioniert.
sbkrogers
1
Ja, entfernen Sie einfach die Zeilen system.net.http und system.runtime. Dann wird es gut.
ZZZ
32

In einem meiner Projekte gab es ein Nuget-Paket mit einer höheren Version von System.Net.Http. und in meinem Startprojekt, das auf System.Net.Http v 4.0.0 verweist, habe ich gerade das System.Net.Http-Nuget-Paket in meinem Startprojekt installiert und das Problem gelöst

RAM
quelle
Ich habe drei Projekte in einer Lösung - nennen wir sie A, Bund C. Aist das Startprojekt und hat nichts mit entweder Boder zu tun C. Cist ein Testprojekt für B. Das Ausführen meiner Tests ist Cfehlgeschlagen, da ich kein Referenzprojekt (System.Net.Http) Ahatte.
Rasmus Bækgaard
19

Ändern Sie Folgendes:

<bindingRedirect oldVersion="0.0.0.0-4.1.1.2" newVersion="4.1.1.2" />

mit den folgenden:

<bindingRedirect oldVersion="0.0.0.0-4.1.1.2" newVersion="4.0.0.0" />

in web.config

Muhammad Waqas
quelle
1
Du bist ein Gangster. Das hat mein Problem gelöst!
Leonardo Wildt
1
Danke @LeonardoWildt
Muhammad Waqas
12

Wenn Ihre Lösung mehrere Projekte enthält, klicken Sie mit der rechten Maustaste auf das Lösungssymbol in Visual Studio und wählen Sie "NuGet-Pakete für Lösung verwalten". Klicken Sie dann auf die vierte Registerkarte "Konsolidieren", um alle Ihre Projekte auf dieselbe Version von zu konsolidieren DLLs. Dadurch erhalten Sie eine Liste der zu konsolidierenden Assemblys, auf die verwiesen werden soll. Klicken Sie auf jedes Element in der Liste und dann auf der Registerkarte rechts auf Installieren.

Wahrheitssucher
quelle
4
Kombinieren Sie dies mit der Antwort von @sajeetharan zur Verwendung von AutoGenerateBindingRedirects. Es scheint, dass ältere Versionen von VS- oder Nuget-Paketen möglicherweise falsche Bindungsanweisungen hinterlassen. Eine gute Reinigung kann viel helfen.
Chris Schaller
11

Die obige Bindungsumleitung hat bei mir nicht funktioniert, daher habe ich den Verweis auf System.Net.Httpin auskommentiert web.config. Ohne es scheint alles in Ordnung zu sein.

  <system.web>
    <compilation debug="true" targetFramework="4.7.2">
      <assemblies>
        <!--<add assembly="System.Net.Http, Version=4.2.0.0, Culture=neutral, PublicKeyToken=B03F5F7F11D50A3A" />-->
        <add assembly="System.ComponentModel.Composition, Version=4.0.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089" />
      </assemblies>
    </compilation>
    <customErrors mode="Off" />
    <httpRuntime targetFramework="4.7.2" />
  </system.web>
Kennzeichen
quelle
1
Dies funktioniert in Visual Studio 2017 (15.9.4) und ermöglicht Ihnen das Erstellen mit dem NuGet-Paket System.Net.Http (4.3.4) anstelle eines direkten Verweises auf die DLL, die mit der Framework-Version .NET 4.7.2 geliefert wird. Gehen Sie folgendermaßen vor, um die ausgelieferte Referenz (ohne weitere Abhängigkeiten) in der IDE zu verwenden: 1) Entfernen Sie die Bindungsumleitungen web / app.config. 2) Entfernen Sie das NuGet-Paket für System.Net.Http. 3) Öffnen Sie "Neue Referenz hinzufügen" und verknüpfen Sie sie direkt auf den neuen Build 4.2.0.0, der mit .NET 4.7 geliefert wird.
EnocNRoll - AnandaGopal Pardue
Dies funktionierte für mich in VS2019 und migrierte eine App von 4.6.1 auf 4.7.2
cklimowski
Ich hatte ein Konsolen-App-Projekt, das als Webjob arbeitete. Diese Ausnahme wurde beim Erstellen eines SendGrid-API-Clients ausgelöst. Alles begann zu funktionieren, nachdem die Bindungsumleitung aus app.config entfernt wurde. Danke, dass du das vorgeschlagen hast, hätte ich nie gedacht.
kurdemol94
9

Sie können dies beheben, indem Sie Ihr Projekt auf .NET Framework 4.7.2 aktualisieren. Dies wurde von Alex Ghiondea - MSFT beantwortet . Bitte stimmen Sie ihn ab, da er es wirklich verdient!

Dies ist in .NET Framework 4.7.1 als bekanntes Problem dokumentiert.

Um dieses Problem zu umgehen, können Sie diese Ziele zu Ihrem Projekt hinzufügen. Sie entfernen den DesignFacadesToFilter aus der Liste der an SGEN übergebenen Referenzen (und fügen sie wieder hinzu, sobald SGEN fertig ist).

<Target Name="RemoveDesignTimeFacadesBeforeSGen" BeforeTargets="GenerateSerializationAssemblies">
  <ItemGroup>
    <DesignFacadesToFilter Include="System.IO.Compression.ZipFile" />
    <_FilterOutFromReferencePath Include="@(_DesignTimeFacadeAssemblies_Names->'%(OriginalIdentity)')" 
        Condition="'@(DesignFacadesToFilter)' == '@(_DesignTimeFacadeAssemblies_Names)' and '%(Identity)' != ''" /> 
    <ReferencePath Remove="@(_FilterOutFromReferencePath)" />
  </ItemGroup>
  <Message Importance="normal" Text="Removing DesignTimeFacades from ReferencePath before running SGen." /> </Target>

<Target Name="ReAddDesignTimeFacadesBeforeSGen" AfterTargets="GenerateSerializationAssemblies">
  <ItemGroup>
    <ReferencePath Include="@(_FilterOutFromReferencePath)" />
  </ItemGroup>
  <Message Importance="normal" Text="Adding back DesignTimeFacades from ReferencePath now that SGen has ran." />
</Target>

Eine weitere Option (maschinenweit) besteht darin, die folgende Bindungsumleitung zu sgen.exe.config hinzuzufügen:

<runtime>
  <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
    <dependentAssembly>
      <assemblyIdentity name="System.IO.Compression.ZipFile" publicKeyToken="b77a5c561934e089" culture="neutral" />
      <bindingRedirect oldVersion="0.0.0.0-4.2.0.0" newVersion="4.0.0.0" />
    </dependentAssembly>
  </assemblyBinding>
</runtime> This will only work on machines with .NET Framework 4.7.1. installed. Once .NET Framework 4.7.2 is installed on that machine, this workaround should be removed.
Boško Bezik
quelle
Diese Antwort auf die obige Linkfrage ist jetzt die relevante Antwort: stackoverflow.com/a/52883065/54289 Einzelheiten finden Sie in den Kommentaren zur Antwort.
EnocNRoll - AnandaGopal Pardue
6

Dies funktioniert in .NET 4.7.2 mit Visual Studio 2017 (15.9.4):

  • Entfernen Sie die Bindungsumleitungen für web / app.config
  • Entfernen Sie das NuGet-Paket für System.Net.Http
  • Öffnen Sie "Neue Referenz hinzufügen" und verknüpfen Sie direkt mit dem neuen Build 4.2.0.0, der mit .NET 4.7.2 geliefert wird

! [Bild] (https://user-images.githubusercontent.com/38843378/50998531-b5bb3a00-14f5-11e9-92df-6c590c469349.png)

EnocNRoll - AnandaGopal Pardue
quelle
4

Ich habe das gleiche Problem und nur, wie ich es beheben kann, ist das Hinzufügen von bindingRedirect zu app.confing, wie @ tripletdad99 geschrieben wurde.

Aber wenn Sie eine Lösung mit mehr Projekt haben, ist es wirklich scheiße, jedes Projekt von Hand zu aktualisieren (und manchmal müssen Sie es nach dem Aktualisieren eines Nuget-Pakets erneut tun). Und es ist Grund, warum ich ein einfaches Powershell-Skript geschrieben habe, das alle app.configs enthält.

 param(
    [string]$SourceDirectory,
    [string]$Package,
    [string]$OldVersion,
    [string]$NewVersion
)

Write-Host "Start fixing app.config in $sourceDirectory"
Write-Host "$Package set oldVersion to $OldVersion and newVersion $NewVersion"
Write-Host "Search app.config files.."
[array]$files = get-childitem $sourceDirectory -Include app.config App.config -Recurse | select -expand FullName
foreach ($file in $files)
{
    Write-Host $file
    $xml = [xml](Get-Content $file)
    $daNodes = $xml.configuration.runtime.assemblyBinding.dependentAssembly
    foreach($node in $daNodes)
    {
        if($node.assemblyIdentity.name -eq $package)
        {
            $updateNode = $node.bindingRedirect
            $updateNode.oldVersion = $OldVersion
            $updateNode.newVersion =$NewVersion
            Write-Host "Fix"
        }
    }
    $xml.Save($file)
}

Write-Host "Done"

Beispiel für die Verwendung:

./scripts/FixAppConfig.ps1 -SourceDirectory "C:\project-folder" -Package "System.Net.Http" -OldVersion "0.0.0.0-4.3.2.0" -NewVersion "4.0.0.0"

Wahrscheinlich ist es nicht perfekt und es ist auch besser, wenn jemand es mit einer vorgefertigten Aufgabe verknüpft.

Jiri Sykora
quelle
3

4.6.1-2 In VS2017 können Benutzer möglicherweise unerwünschte Ersetzungen ihrer Version von System.Net.Http durch die Version erfahren, die VS2017 oder Msbuild 15 verwenden möchten.

Wir haben diese Version hier gelöscht:

C: \ Programme (x86) \ Microsoft Visual Studio \ 2017 \ Professional \ MSBuild \ Microsoft \ Microsoft.NET.Build.Extensions \ net461 \ lib \ System.Net.Http.dll

und hier:

C: \ Programme (x86) \ Microsoft Visual Studio \ 2017 \ BuildTools \ MSBuild \ Microsoft \ Microsoft.NET.Build.Extensions \ net461 \ lib \ System.Net.Http.dll

Anschließend wird das Projekt mit der Version erstellt, auf die wir über NuGet verwiesen haben.

Jaybro
quelle
1

Ich hatte dies, aber es war, weil ich ein NuGet-Paket hinzugefügt hatte, das die Bindungsumleitungen aktualisiert hatte. Nachdem ich das Paket entfernt hatte, waren die Weiterleitungen noch vorhanden. Ich habe alle entfernt und dann update-package -reinstall ausgeführt. Dies fügte die richtigen Weiterleitungen hinzu.

SwampyFox
quelle
0

Überprüfen Sie die .net Framework-Version.
Mein ursprüngliches .net-Framework ist eine ältere Version.
Nachdem ich .net Framework 4.6 installiert habe, wird dieses Problem automatisch behoben.

Frank Myat Do.
quelle
0

Für mich hatte ich mein Projekt so eingestellt, dass es auf der neuesten Version von .Net Framework ausgeführt wird (eine Änderung von .Net Framework 4.6.1 auf 4.7.2).

Alles hat funktioniert, keine Fehler und ohne Probleme veröffentlicht, und es war nur ein Zufall, dass ich auf die System.Net.Http-Fehlermeldung gestoßen bin, die in einer kleinen, schwer zu erkennenden, aber ziemlich wichtigen API-Anfrage über die Website I 'angezeigt wird. Ich arbeite daran.

Ich habe auf 4.6.1 zurückgesetzt und alles ist wieder in Ordnung.

Stuart Aitken
quelle
0

Die einzige Möglichkeit, dieses Problem für mich (.NET 4.6.1) sauber zu lösen, bestand darin, nicht nur einen Nuget-Verweis auf System.Net.Http V4.3.4 für das Projekt hinzuzufügen, das tatsächlich System.Net.Http verwendet hat, sondern auch auf das Startprojekt (in meinem Fall ein Testprojekt).

(Was seltsam ist, da die richtige System.Net.Http.dll im bin-Verzeichnis des Testprojekts vorhanden war und die .config-AssemblyBingings ebenfalls in Ordnung aussahen.)

TvdH
quelle
0

Aktualisierte eine alte Website mit Nuget (einschließlich .Net-Update und MVC-Update).

Ich habe die System.Net.HTTP-Referenz in VS2017 gelöscht (es war Version 2.0.0.0) und die Referenz erneut hinzugefügt, die dann 4.2.0.0 zeigte.

Ich habe dann eine Menge 'Pakete' mit Nuget aktualisiert und die Fehlermeldung erhalten. Dann habe ich festgestellt, dass etwas den Verweis auf 2.0.0.0 zurückgesetzt hat, also habe ich ihn entfernt und wieder hinzugefügt und es funktioniert einwandfrei ... bizarr.

Paul Zahra
quelle