Nie można załadować pliku lub zestawu „System.Net.Http, Version = 4.0.0.0, Culture = neutral, PublicKeyToken = b03f5f7f11d50a3a”

Skopiowałem swój projekt na czystą maszynę z systemem Windows 10 z zainstalowanymi tylko Visual Studio 2015 Community i SQL Server 2016 Express. Nie ma innych zainstalowanych wersji frameworka oprócz tych zainstalowanych z Windows 10 i VS2015 lub SQL Server.

Kiedy próbuję uruchomić projekt WebApi, otrzymuję komunikat:

Nie można załadować pliku lub zestawu „System.Net.Http, Version = 4.0.0.0, Culture = neutral, PublicKeyToken = b03f5f7f11d50a3a” lub jednej z jego zależności. System nie może odnaleźć określonego pliku.

Pakiety projektu obejmują:

<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" />

Po skompilowaniu projektu za pomocą .NET Framework 4.6.1 System.Net.Httpplik nie znajduje się w binfolderze.

Ścieżka do pliku wskazuje na:

C: \ Program Files (x86) \ Reference Assemblies \ Microsoft \ Framework.NETFramework \ v4.6.1 \ System.Net.Http.dll

Ścieżka do pliku System.Net.Http.Formattingwskazuje na:

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

Czy cały projekt powinien być ukierunkowany na 4.5.1, czy też istnieje inny sposób odniesienia się do właściwych zespołów?

Wykonaj następujące kroki,

1. Zaktualizuj Visual Studio do najnowszej wersji (to ma znaczenie)
2. Usuń wszystkie przekierowania powiązań z web.config

3. Dodaj to do .csprojpliku:

   <PropertyGroup>
     <AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects>
     <GenerateBindingRedirectsOutputType>true</GenerateBindingRedirectsOutputType>
   </PropertyGroup>

4. Zbuduj projekt
5. W binfolderze powinien znajdować się (WebAppName).dll.configplik
6. Powinien zawierać przekierowania, skopiuj je do pliku web.config
7. Usuń powyższe wycięte z .csprojpliku

Powinno działać

Zmiana informacji o powiązaniach w moim web.config (lub app.config) - podczas gdy w moim widoku „hack” pozwala na kontynuowanie projektu po aktualizacji pakietu NuGet, która włamuje się do aplikacji i daje plik System.Net.Http błąd.

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

W jednym z moich projektów był pakiet NuGet z wyższą wersją System.Net.Http. aw moim projekcie startowym jest odniesienie do System.Net.Http v 4.0.0, właśnie zainstalowałem pakiet System.Net.Http nuget w moim projekcie startowym i problem został rozwiązany

Zmień następujące:

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

z następującymi:

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

w web.config

Jeśli masz wiele projektów w swoim rozwiązaniu, kliknij prawym przyciskiem myszy ikonę rozwiązania w programie Visual Studio i wybierz opcję „Zarządzaj pakietami NuGet dla rozwiązania”, a następnie kliknij czwartą kartę „Konsoliduj”, aby skonsolidować wszystkie swoje projekty w tej samej wersji Biblioteki DLL. Spowoduje to wyświetlenie listy zestawów, do których istnieją odniesienia, do konsolidacji. Kliknij każdą pozycję na liście, a następnie kliknij zainstaluj na karcie, która pojawi się po prawej stronie.

Powyższe przekierowanie bind nie działa dla mnie, więc skomentowałem odniesienie do System.Net.Httpin web.config. Wszystko wydaje się działać bez niego.

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

Możesz to naprawić, uaktualniając projekt do programu .NET Framework 4.7.2. Zostało to odebrane przez Alex Ghiondea - MSFT . Proszę, zagłosuj na niego tak, jak naprawdę na to zasługuje!

Jest to udokumentowane jako znany problem w programie .NET Framework 4.7.1.

Aby obejść ten problem, możesz dodać te cele do projektu. Usuną DesignFacadesToFilter z listy odniesień przekazanych do SGEN (i dodają je z powrotem po zakończeniu SGEN)

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

Inną opcją (dla całego komputera) jest dodanie następującego przekierowania powiązania do sgen.exe.config:

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

To zadziała w .NET 4.7.2 z programem Visual Studio 2017 (15.9.4):

• Usuń przekierowania powiązań web / app.config
• Usuń pakiet NuGet dla System.Net.Http
• Otwórz „Dodaj nowe odwołanie” i połącz bezpośrednio z nową kompilacją 4.2.0.0 dostarczaną z .NET 4.7.2

Mam ten sam problem i jedynym sposobem, w jaki mogę go naprawić, jest dodanie bindingRedirect do app.confing, jak napisał @ tripletdad99.

Ale jeśli masz rozwiązanie z większą liczbą projektów, to naprawdę jest do bani, aktualizuj każdy projekt ręcznie (a także czasami po aktualizacji jakiegoś pakietu nuget musisz to zrobić ponownie). I to jest powód, dla którego napisałem prosty skrypt PowerShell, który, jeśli wszystkie app.configs.

 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"

Przykład użycia:

./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"

Prawdopodobnie nie jest doskonały i będzie lepiej, jeśli ktoś połączy go z zadaniem pre-build.

4.6.1-2 w VS2017 użytkownicy mogą doświadczyć niechcianej zamiany ich wersji System.Net.Http na wersję, której chce użyć VS2017 lub Msbuild 15.

Usunęliśmy tę wersję tutaj:

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

i tu:

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

Następnie projekt jest kompilowany z wersją, do której odwołujemy się za pośrednictwem NuGet.

Miałem to, ale było tak, ponieważ dodałem pakiet NuGet, który zaktualizował przekierowania powiązań. Po usunięciu pakietu przekierowania nadal tam były. Usunąłem je wszystkie, a następnie uruchomiłem update-package -reinstall. To dodało prawidłowe przekierowania.

Sprawdź wersję platformy .net.
Mój oryginalny framework .net jest starszą wersją.
Po zainstalowaniu .NET Framework 4.6 ten problem został automatycznie rozwiązany.

U mnie ustawiłem projekt tak, aby działał na najnowszej wersji .Net Framework (zmiana z .Net Framework 4.6.1 na 4.7.2).

Wszystko działało, bez błędów i opublikowano bez problemu, i tylko przez przypadek trafiłem na komunikat o błędzie System.Net.Http, pokazany w małym, trudnym do zauważenia, ale dość ważnym żądaniu API na stronie internetowej I ' pracuję nad.

Cofnąłem się do wersji 4.6.1 i znowu wszystko jest w porządku.

Jedynym sposobem czystego rozwiązania tego problemu dla mnie (.NET 4.6.1) było nie tylko dodanie odwołania Nuget do System.Net.Http V4.3.4 dla projektu, który faktycznie używał System.Net.Http, ale także projekt startowy (w moim przypadku projekt testowy).

(Co jest dziwne, ponieważ poprawna System.Net.Http.dll istniała w katalogu bin projektu testowego, a plik .config assemblyBingings również wyglądał dobrze).

Aktualizacja starej witryny sieci Web przy użyciu nuget (w tym aktualizacji .Net i aktualizacji MVC).

Usunąłem odwołanie System.Net.HTTP w VS2017 (była to wersja 2.0.0.0) i ponownie dodałem odwołanie, które następnie pokazało 4.2.0.0.

Następnie zaktualizowałem mnóstwo `` pakietów '' za pomocą nuget i otrzymałem komunikat o błędzie, a następnie zauważyłem, że coś zresetowało odniesienie do 2.0.0.0, więc usunąłem i ponownie dodałem i działa dobrze ... dziwne.