Não foi possível carregar o arquivo ou o conjunto “System.Net.Http, Versão = 4.0.0.0, Culture = Neutral, PublicKeyToken = b03f5f7f11d50a3a”

Copiei meu projeto para uma máquina limpa do Windows 10 com apenas a Comunidade do Visual Studio 2015 e o SQL Server 2016 Express instalados. Não há outras versões da estrutura instaladas além daquelas instaladas no Windows 10 e VS2015 ou SQL Server.

Quando tento iniciar o projeto WebApi, recebo a mensagem:

Não foi possível carregar o arquivo ou o conjunto "System.Net.Http, Versão = 4.0.0.0, Cultura = neutro, PublicKeyToken = b03f5f7f11d50a3a" ou uma de suas dependências. O sistema não pode encontrar o arquivo especificado.

Os pacotes do projeto incluem:

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

Depois de criar o projeto com o .NET Framework 4.6.1, System.Net.Httpo arquivo não foi encontrado na binpasta

O caminho do arquivo aponta para:

C: \ Arquivos de programas (x86) \ Assemblies de referência \ Microsoft \ Framework.NETFramework \ v4.6.1 \ System.Net.Http.dll

O caminho do arquivo de System.Net.Http.Formattingpontos para:

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

Todo o projeto deve ser direcionado para o item 4.5.1 ou existe outra maneira de referenciar os assemblies certos?

Siga os seguintes passos,

1. Atualize o visual studio para a versão mais recente (é importante)
2. Remova todos os redirecionamentos de ligação de web.config

3. Adicione isso ao .csprojarquivo:

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

4. Construa o projeto
5. Na binpasta deve haver um (WebAppName).dll.configarquivo
6. Deveria ter redirecionamentos, copie-os para o diretório web.config
7. Remova o snippet acima do .csprojarquivo

Deveria funcionar

Alterando as informações de ligação em meu web.config (ou app.config) - enquanto um "hack", na minha opinião, permite avançar com seu projeto após uma atualização de pacote NuGet que afeta seu aplicativo e fornece o System.Net.Http erro.

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

Em um dos meus projetos, havia pacotes de nuget com a versão superior do System.Net.Http. e no meu projeto de inicialização, há referência ao System.Net.Http v 4.0.0, acabei de instalar o pacote nuget System.Net.Http no meu projeto de inicialização e o problema foi resolvido

Alterar a seguir:

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

com o seguinte:

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

no web.config

Se você tiver vários projetos em sua solução, clique com o botão direito do mouse no ícone da solução no Visual Studio e selecione 'Gerenciar pacotes NuGet para solução' e clique na quarta guia 'Consolidar' para consolidar todos os seus projetos na mesma versão do DLLs. Isso fornecerá uma lista de montagens referenciadas para consolidar. Clique em cada item da lista e clique em instalar na guia que aparece à direita.

O bind-redirect acima não funcionou para mim, então comentei a referência a System.Net.Httpin web.config. Tudo parece funcionar bem sem ele.

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

Você pode corrigir isso, atualizando seu projeto para o .NET Framework 4.7.2. Isso foi respondido por Alex Ghiondea - MSFT . Por favor, vote-o como ele realmente merece!

Isso está documentado como um problema conhecido no .NET Framework 4.7.1.

Como solução alternativa, você pode adicionar esses destinos ao seu projeto. Eles removerão o DesignFacadesToFilter da lista de referências passadas ao SGEN (e os adicionarão novamente assim que o SGEN for concluído)

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

Outra opção (em toda a máquina) é adicionar o seguinte redirecionamento de ligação ao 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.

Isso funcionará no .NET 4.7.2 com Visual Studio 2017 (15.9.4):

• Remova os redirecionamentos de ligação web / app.config
• Remova o pacote NuGet para System.Net.Http
• Abra "Adicionar nova referência" e vincule diretamente à nova versão 4.2.0.0 que acompanha o .NET 4.7.2

Tenho o mesmo problema e a única maneira de corrigi-lo é adicionar bindingRedirect ao app.confing como escreveu @ tripletdad99.

Mas se você tiver uma solução com mais projeto, é realmente uma chatice atualizar todos os projetos manualmente (e também, algumas vezes, depois de atualizar algum pacote de nuget, é necessário fazê-lo novamente). E é por isso que eu escrevi um script simples do PowerShell, que se todos os 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"

Exemplo de como usar:

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

Provavelmente não é perfeito e também será melhor se alguém o vincular à tarefa de pré-construção.

4.6.1-2 no VS2017, os usuários podem enfrentar a substituição indesejada de sua versão do System.Net.Http pela que o VS2017 ou o Msbuild 15 deseja usar.

Excluímos esta versão aqui:

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

e aqui:

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

Em seguida, o projeto é construído com a versão que referenciamos via NuGet.

Eu tinha isso, mas foi porque adicionei um pacote NuGet que atualizou os redirecionamentos de ligação. Depois que removi o pacote, os redirecionamentos ainda estavam lá. Removai todos eles e, em seguida, executei o update-package-reinstall. Isso adicionou os redirecionamentos corretos.

Verifique a versão da estrutura .net.
Minha estrutura .net original é uma versão mais antiga.
Depois de instalar o .net framework 4.6, esse problema é resolvido automaticamente.

Para mim, configurei meu projeto para ser executado na versão mais recente do .Net Framework (uma alteração do .Net Framework 4.6.1 para 4.7.2).

Tudo funcionou, sem erros e publicado sem problemas, e foi por acaso que me deparei com a mensagem de erro System.Net.Http, mostrada em uma solicitação de API pequena, difícil de perceber, mas muito importante no site ' estou trabalhando.

Voltei para 4.6.1 e está tudo bem novamente.

A única maneira de resolver esse problema de maneira limpa (.NET 4.6.1) foi não apenas adicionar uma referência Nuget ao System.Net.Http V4.3.4 para o projeto que realmente usou o System.Net.Http, mas também ao projeto de inicialização (um projeto de teste no meu caso).

(O que é estranho, porque o System.Net.Http.dll correto existia no diretório bin do projeto de teste e o .config assemblyBingings também parecia bom.)

Estava atualizando um site antigo usando o nuget (incluindo atualização .Net e MVC).

Excluí a referência System.Net.HTTP no VS2017 (era para a versão 2.0.0.0) e adicionei novamente a referência, que mostrava 4.2.0.0.

Atualizei uma tonelada de 'pacotes' usando o nuget e recebi a mensagem de erro, depois notei que algo havia redefinido a referência para 2.0.0.0, então removi e adicionei novamente e ele funciona bem ... bizarro.