Não foi possível carregar o arquivo ou assembly 'System.Net.Http, Version = 2.0.0.0 na MVC4 Web API

Eu tenho um problema um pouco estranho.
Desenvolvi um aplicativo com MVC 4 e a nova API Web e funciona bem localmente. Instalei MVC4 no servidor e implantei o aplicativo. Agora recebo o seguinte erro:

Não foi possível carregar o arquivo ou assembly 'System.Net.Http, Version = 2.0.0.0, Culture = neutral, PublicKeyToken = 31bf3856ad364e35' ou uma de suas dependências. A definição de manifesto do assembly localizado não corresponde à referência do assembly. (Exceção de HRESULT: 0x80131040)

Descrição: Ocorreu uma exceção não tratada durante a execução da solicitação da web atual. Reveja o rastreamento da pilha para obter mais informações sobre o erro e onde ele se originou

Engraçado, a versão de System.Net.Http que tenho localmente em minha pasta de pacotes ou na pasta ASP.NET MVC 4 \ Assemblies é 1.0.0.0. Na verdade, removi a referência a System.Net.Http do meu projeto, mas ainda recebo a mesma mensagem. Estou um pouco confuso sobre de onde vem a referência 2.0.0.0 e por que funcionaria localmente, mas não no servidor.

Olhando para as dependências do nuget:

As bibliotecas básicas da API ASP.NET WEb (Beta) dependem de System.Net.Http.Formatting.
E System.Net.Http.Formatting depende de System.Net.Http.
Acho que é daí que vem isso. Mas eu tenho a versão 2.0.20126.16343 deste pacote instalada, só que a dll dentro tem a versão 1.0.0.0

Estou esquecendo de algo?

ATUALIZAR:

Este é um subaplicativo de outro aplicativo ASP.NET, mas o outro ainda é baseado em WebForms. Então, algo está ficando confuso. Mas se eu fizer uma limpeza na seção de montagem do web.config, ele nem encontrará mais o aplicativo.

Tive o mesmo problema ao implantar meu aplicativo no appharbor. O problema é que ainda não há suporte para .NET 4.5. O que eu fiz.

1. Mudei meu projeto para o perfil .NET 4.0.
2. Pacote NuGet da API Web desinstalado.
3. Pacote NuGet da API da Web (Beta) instalado novamente.
4. Verificou-se que o arquivo .csproj contém para TODOS os assemblies referenciados, portanto, ele sempre o obterá da pasta Bin, em vez do GAC.

Eu tive o mesmo erro ao implantar o aplicativo da web convertido anteriormente (de .NET 4.5 para 4.0) no IIS 6.0.

Na seção de tempo de execução web.config , encontrei

<dependentAssembly>
    <assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
    <bindingRedirect oldVersion="0.0.0.0-4.0.0.0" newVersion="4.0.0.0"/>
</dependentAssembly>

que eu mudei para

<dependentAssembly>
    <assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
    <bindingRedirect oldVersion="0.0.0.0-1.0.0.0" newVersion="2.0.0.0"/>
</dependentAssembly>

Agora funciona como charme.

O meu trabalhou com:

Observe o redirecionamento de 1-4 para 2.0

<dependentAssembly>
    <assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a"   culture="neutral"/>
    <bindingRedirect oldVersion="0.0.0.0-4.0.0.0" newVersion="2.0.0.0"/>
</dependentAssembly>

Na pasta References do seu projeto deve haver uma referência a esta dll, e a versão deve ser 2.0.0.0. Certifique-se de que esteja definido como Copy Local = true. Em seguida, certifique-se de que ele encontra o caminho para a pasta bin do aplicativo do servidor.

Esta é uma das bibliotecas que agora é gerenciada pelo nuget. Portanto, abra o Nuget e verifique se tudo está atualizado. E no diretório de pacotes de seus projetos, o arquivo deve estar aqui: \packages\System.Net.Http.2.0.20126.16343\lib\net40

Você também pode tentar criar um novo aplicativo MVC4 e ver se o arquivo aparece para aquele.

No meu caso, corrigi de uma maneira muito mais fácil, basta dar um HintPath para a referência ao pacote nuget:

     <Reference Include="System.Data.Entity" />
     <Reference Include="System.Net.Http, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a">
       <Private>True</Private>
+      <HintPath>..\..\packages\Microsoft.Net.Http.2.0.20710.0\lib\net40\System.Net.Http.dll</HintPath>
     </Reference>
     <Reference Include="System.Net.Http.WebRequest, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a">
       <Private>True</Private>
+      <HintPath>..\..\packages\Microsoft.Net.Http.2.0.20710.0\lib\net40\System.Net.Http.WebRequest.dll</HintPath>
     </Reference>
     <Reference Include="System.Numerics" />
     <Reference Include="System.Security" />

No meu caso, adicionei sem querer uma dependência ao System.Net.Http versão 2.1.10.0 por meio do NuGet. Não consegui me livrar dele no Gerenciador de Pacotes NuGet (porque outros pacotes pareciam depender dele). No entanto, esses pacotes não dependem desta versão em particular. Aqui está o que fiz para me livrar dele (você também pode usar o console NuGet (usando o parâmetro –force):

• Altere a versão de Microsoft.Net.Http em packages.config de 2.1.10.0 para 2.0.0.0
• Desinstale o BCL Portability Pack no NuGet Package Manager
• Livre-se manualmente das bibliotecas dependentes (System.Net.Http. * Que tem a versão 2.1.10.0)
• Adicione uma referência a System.Net.Http 2.0.0.0

Na configuração do arquivo, excluí o Assembly dependente:

<dependentAssembly>
    <assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
    <bindingRedirect oldVersion="0.0.0.0-4.0.0.0" newVersion="2.0.0.0"/>
<dependentAssembly>

Agora funciona bem.

Eu estava enfrentando esse problema em um servidor de teste (Windows 2008 R2) que supostamente estava "pronto" para implantação;)

A dica era que, quando verifiquei as versões do System.net entre minha máquina DEV e o servidor de implantação, elas não correspondiam.

Corrigido usando as etapas abaixo:

1. Baixe o instalador independente do .NET Framework 4.5 AQUI

2. Executou o instalador na máquina de implantação

Após a instalação do framework, o servidor queria uma reinicialização, então fiz isso e volla! Estamos prontos para ir !!

Estamos usando o VS 2013, criamos uma nova API da Web MVC 4 e tivemos um problema com o system.net.http.dll não sendo a versão correta quando construído em nosso servidor TeamCity, mas ele funciona bem em nossas máquinas de desenvolvedor locais que têm VS 2013 instalado.

Finalmente determinamos o problema.

Ao criar uma nova API MVC 4 Web e escolher a estrutura 4.0 na criação do projeto, descobrimos que a versão correta do pacote NuGet para DLL estava sendo colocada em: .. \ packages \ Microsoft.Net.Http.2.0.20710.0 \ lib \ net40 \ System.Net.Http.dll

No entanto, o arquivo .csproj para este projeto disse que o caminho para este arquivo system.net.http.dll é: .. \ packages \ Microsoft.Net.Http.2.0.30506.0 \ lib \ net40 \ System.Net.Http.dll

Portanto, quando a tentativa de construção falha nesta diferença de caminho, mas está encontrando a versão de estrutura correta do arquivo em outro lugar na máquina do desenvolvedor, mas não em nosso servidor de construção TeamCity.

Até agora, esta é a única diferença que encontramos. Alterar o caminho no arquivo .csproj e construir na máquina Dev local com VS2013 ainda funciona em localizar.

Verificar isso no controle de versão e ter nosso servidor de compilação TeamCity (sem o VS 2013 instalado localmente) agora encontra a versão correta do .dll em sua pasta de pacote NuGet para a solução e compila com sucesso em vez de procurar outra versão de system.net.http .dll e encontrar uma versão mais recente que não corresponda à estrutura, causando falhas de compilação.

Não tenho certeza se isso ajuda.

Verifique o caminho do arquivo de projeto para a DLL e certifique-se de que corresponde ao caminho da pasta do pacote para a DLL.

Apenas simplificando as outras respostas para o que funcionou para mim.

Eu fui para o gerenciador NuGet, desinstalei os pacotes relacionados (no meu caso, "Bibliotecas de cliente Microsoft ASP.NET Web API 2.1" e "Json.NET") e os reinstalei. Bastou alguns cliques.

Feche o projeto, abra-o novamente. Em seguida, Clean Solution + Build. Funciona para mim

Para a versão 2.2.15.0, fiz o seguinte:

<dependentAssembly>
    <assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
    <bindingRedirect oldVersion="0.0.0.0-4.0.0.0" newVersion="2.2.15.0"/>
</dependentAssembly>

Eu tive exatamente o mesmo problema! Dei uma olhada na minha guia Avisos no VS e percebi que um dos meus pacotes nuget fazia referência INDIRETAMENTE ao .NETFramework versão 4.5.0.0. Tive que desinstalar este pacote e, em seguida, reinstalar a versão 4.0, mas certifique-se de especificar as versões do pacote que suportam 4.0 (o padrão voltará para 4.5, acredito que se você não especificar ao instalar o pacote). Espero que isto ajude!

Isso aconteceu em um servidor após a implantação. Foi causado por:

A) Arquivos antigos na pasta bin ainda pendurados e que deveriam ter sido excluídos

ou

B) Não ter acesso de leitura à pasta para o usuário Application Pool Identity.

Em outras palavras, para nós, isso foi resolvido corrigindo as permissões nas pastas do site, apagando a pasta bin e reimplantando.

Tive o mesmo problema com Gembox.spreadsheet.dll versão 31.

"Não foi possível carregar o arquivo ou assembly 'GemBox.Spreadsheet, Version = 39.3.30.1095, Culture = neutral, PublicKeyToken = b1b72c69714d4847' ou uma de suas dependências. A definição de manifesto do assembly localizado não corresponde à referência do assembly. (Exceção de HRESULT: 0x80131040 ) "

Tentei quase tudo com esses artigos e nenhum deles funcionou. Ele só foi corrigido com um passo simples.

Tentei construir projetos individuais que basicamente configuravam a referência de versão correta para a dll e o erro havia desaparecido totalmente da solução.

Vá para um problema semelhante e a diretiva mencionada em muitos comentários funcionou bem

<dependentAssembly>
    <assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
    <bindingRedirect oldVersion="0.0.0.0-4.0.0.0" newVersion="2.0.0.0"/>
<dependentAssembly>

Embora você tenha que garantir que a cobertura da versão antiga seja alta o suficiente, caso contrário, as versões mais recentes podem não ser redirecionadas para a versão específica que você precisa e o local que usa essa referência mais recente não funcionará corretamente, pois a referência mais antiga já está no diretório bin.

Para este erro (e similar), vale a pena passar pelo NuGet Consolidate (Solução> Gerenciar Pacotes NuGet ...) para garantir que as mesmas versões de componentes referenciados sejam consistentes em cada biblioteca de classes referenciada na solução, uma vez que mesmo uma versão ligeiramente mais antiga pode ter dependências em outros componentes mais antigos. É fácil de usar em conjunto com as atualizações e pode evitar muitos problemas.

Isso resolveu esse problema para mim e eu diria que é obrigatório se familiarizar se você estiver criando bibliotecas auxiliares que também fazem referência a MVC ou outros componentes NuGet baseados na web.