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

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?

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

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

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

Ä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

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.

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>

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.

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

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.

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.

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.

Ü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.

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.

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.)

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.