Problema estranho com System.Net.Http 4.2.0.0 não encontrado

Eu tenho um problema estranho, que me deixa louco ...

Eu tenho um projeto de biblioteca de classes simples (Full .NET Framework, 4.6.1) com uma classe de wrapper para funcionalidade em torno do Cosmos DB. Portanto, adicionei o Pacote NuGet 1.19.1 “Microsoft.Azure.DocumentDB” a este projeto. Além disso, tenho uma referência ao pacote NuGet 10.0.3 “Newtonsoft.Json”, bem como a alguns pacotes NuGet "Microsoft.Diagnostics.EventFlow. *".

Até agora, tudo compila sem nenhum erro.

Mas assim que eu atingir minha classe de wrapper - consumida de um serviço sem estado do Service Fabric simples (.NET Framework 4.6.1 completo) - e tento executar a seguinte linha de código:

_docClient = new DocumentClient(new Uri(cosmosDbEndpointUrl), cosmosDbAuthKey);

Eu recebo este erro estranho em tempo de execução:

System.IO.FileNotFoundException ocorreu HResult = 0x80070002
Message = Não foi possível carregar o arquivo ou assembly 'System.Net.Http, Version = 4.2.0.0, Culture = neutral, PublicKeyToken = b03f5f7f11d50a3a' ou uma de suas dependências. O sistema não pode encontrar o arquivo especificado.
Source = StackTrace: em Microsoft.Azure.Documents.Client.DocumentClient.Initialize (Uri serviceEndpoint, ConnectionPolicy connectionPolicy, Nullable 1 desiredConsistencyLevel) at Microsoft.Azure.Documents.Client.DocumentClient..ctor(Uri serviceEndpoint, String authKeyOrResourceToken, ConnectionPolicy connectionPolicy, Nullable1 neededConsistencyLevel)

Exceção interna 1: FileNotFoundException: não foi possível carregar o arquivo ou assembly 'System.Net.Http, Version = 4.0.0.0, Culture = neutral, PublicKeyToken = b03f5f7f11d50a3a' ou uma de suas dependências. O sistema não pode encontrar o arquivo especificado.

Eu não tenho absolutamente nenhuma ideia de por que o assembly System.Net.Http não foi encontrado - há até uma referência de assembly em meu projeto de biblioteca de classe para o assembly .Net Framework “System.Net.Http 4.0.0.0”.

O que eu também não entendo é que existe esse redirecionamento estranho de vinculação para 4.2.0.0 - de onde vem esse? Para contornar este, tentei adicionar o seguinte redirecionamento ao app.config do Service Fabric Service (que está consumindo a biblioteca de classes):

Mas ainda sem diferença, ainda recebo o erro em tempo de execução.

Alguém tem uma pista? Alguém já viu esse problema?

Obrigado e cumprimentos, OliverB

O problema que você está enfrentando está relacionado ao Visual Studio, especialmente 2017, que é fornecido com ele System.Net.Http v4.2.0.0. No entanto, adotando a nova forma em que todas as referências devem ser feitas via NuGet, a última versão da System.Net.Httpqual é 4.3.3 contém a dll versão 4.1.1.2.

O problema é que o VS em tempo de compilação e em tempo de execução também irá ignorar sua referência e tentará fazer referência à DLL que conhece.

Como corrigi-lo:

• certifique-se de que todas as referências a System.Net.Http sejam feitas por meio do NuGet
• Erros de tempo de compilação: altere a extensão de System.Net.Http.dll (ou mova-o para outro lugar ... basicamente livre-se dele) que acompanha o VS 2017 ( c:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net461\lib\); se você tiver uma versão diferente, o caminho será um pouco diferente, mas não muito

• Erros de tempo de execução: adicione um redirecionamento de associação de assembly

Se você procurar on-line no Google, encontrará alguns problemas em aberto com a Microsoft sobre isso, então, espero que eles consigam isso no futuro.

Espero que isto ajude.

Atualizar:

Ao procurar algumas correções permanentes para esse problema para funcionar nos agentes de compilação, observe que se você migrar para o novo modelo NuGet PackageReference (em .csprojnão em packages.config), ele tende a funcionar melhor. Aqui está um link para o guia sobre como fazer esta atualização: https://docs.microsoft.com/en-us/nuget/reference/migrate-packages-config-to-package-reference

A remoção do redirecionamento de ligação funcionou para mim, você pode tentar removê-lo:

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

Um complemento à resposta que @AndreiU já deu e como reproduzir erros de execução localmente.

Recebi o erro de tempo de execução abaixo ao implantar no Azure, não localmente.

Não foi possível carregar o arquivo ou assembly 'System.Net.Http, Version = 4.2.0.0, Culture = neutral, PublicKeyToken = b03f5f7f11d50a3a' ou uma de suas dependências. O sistema não pode encontrar o arquivo especificado. "," ExceptionType ":" System.IO.FileNotFoundException "," StackTrace ":" em Company.Project.Service.CompanyIntegrationApiService..ctor (Uri baseAddress) \ r \ n em Company.Project .BackOffice.Web.Controllers.OrderController..ctor () em C: \ projects \ company-project \ src \ Company.Project.BackOffice.Web \ Controllers \ Order \ OrderController.cs: linha 30 \ r \ n em lambda_method ( Closure) \ r \ n em System.Web.Http.Dispatcher.DefaultHttpControllerActivator.Create (solicitação HttpRequestMessage, HttpControllerDescriptor controllerDescriptor, Type controllerType) "}} Culture = neutral, PublicKeyToken = b03f5f7f11d50a3a 'ou uma de suas dependências. O sistema não pode encontrar o arquivo especificado. "," ExceptionType ":" System.IO.FileNotFoundException "," StackTrace ":" em Company.Project.Service.CompanyIntegrationApiService..ctor (Uri baseAddress) \ r \ n em Company.Project .BackOffice.Web.Controllers.OrderController..ctor () em C: \ projects \ company-project \ src \ Company.Project.BackOffice.Web \ Controllers \ Order \ OrderController.cs: linha 30 \ r \ n em lambda_method ( Closure) \ r \ n em System.Web.Http.Dispatcher.DefaultHttpControllerActivator.Create (solicitação HttpRequestMessage, HttpControllerDescriptor controllerDescriptor, Type controllerType) "}} Culture = neutral, PublicKeyToken = b03f5f7f11d50a3a 'ou uma de suas dependências. O sistema não pode encontrar o arquivo especificado. "," ExceptionType ":" System.IO.FileNotFoundException "," StackTrace ":" em Company.Project.Service.CompanyIntegrationApiService..ctor (Uri baseAddress) \ r \ n em Company.Project .BackOffice.Web.Controllers.OrderController..ctor () em C: \ projects \ company-project \ src \ Company.Project.BackOffice.Web \ Controllers \ Order \ OrderController.cs: linha 30 \ r \ n em lambda_method ( Closure) \ r \ n em System.Web.Http.Dispatcher.DefaultHttpControllerActivator.Create (solicitação HttpRequestMessage, HttpControllerDescriptor controllerDescriptor, Type controllerType) "}}

Quando comecei a olhar para os assemblies, pude ver que meu projeto da web e projeto de serviço visavam versões diferentes para System.Net.Http.

Projeto web:

Projeto de serviço:

É fácil pensar que isso é causado por uma incompatibilidade de versões, mas a chave aqui é examinar o erro The system cannot find the file specified..

Olhando para a propriedade de caminho, podemos ver que o projeto da web tem como alvo um assembly .Net Framework enquanto o serviço tem como alvo um assembly do Visual Studio 2017. Como o servidor não tem o Visual Studio 2017 instalado, o erro de tempo de execução ocorrerá.

Caminho da web:

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

Caminho do serviço:

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

Algo tão simples como a criação Copy Localde truepode corrigir o problema, porém não em todos os casos.

Para reproduzir o erro em sua máquina local, basta remover o necessário System.Net.Http.dllda pasta específica do Visual Studio. Isso lhe dará o erro de tempo de execução e provavelmente alguns erros de compilação. Depois de consertados, tudo deve funcionar, pelo menos funcionou para mim.

Se você instalou System.Net.Httpvia, NuGetverifique qual assembly é usado, observando a .csprojversão. System.Net.Http 4.3.4dá a seguinte montagem, por exemplo:

<Reference Include="System.Net.Http, Version=4.1.1.3, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL">
  <HintPath>..\packages\System.Net.Http.4.3.4\lib\net46\System.Net.Http.dll</HintPath>
  <Private>True</Private>
  <Private>True</Private>
</Reference>

Se você usar um servidor de compilação como Jenkins, TeamCity ou AppVeyor, o tempo de execução ausente também .dllpode existir lá. Nesse caso, pode não ajudar usar a versão NuGet de System.Net.Http ou excluir o que está faltando .dlllocalmente. Para resolver este erro observe a versão que não foi encontrada e a específica PublicKeyToken. Depois disso, crie um redirecionamento de ligação em um Web.configou App.configdependendo do seu projeto. No meu caso, gostaria de usar 4.0.0.0 em vez disso:

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

Um bom tópico do Github sobre o problema:

https://github.com/dotnet/corefx/issues/22781

Acabei de instalar System.Net.Httpusando NuGet. Você pode pegar aqui:

https://www.nuget.org/packages/System.Net.Http/

O ASP.NET MVCprojeto que estou trabalhando em metas .NET 4.6.1. Funciona perfeitamente na minha máquina durante a depuração IIS Expresscom o Visual Studio 2019.

O problema aconteceu ao tentar executar o aplicativo implantado no Azure. Eu estava recebendo este erro:

Não foi possível carregar o arquivo ou assembly 'System.Net.Http, Version = 4.2.0.0, Culture = neutral, PublicKeyToken = b03f5f7f11d50a3a' ou uma de suas dependências.

O que realmente funcionou no meu caso foi abrir o arquivo .csproj e pesquisar System.Net.Httpcomo na imagem a seguir ...

Veja se o .csprojarquivo tem a versão 4.1.1.3:

<Reference Include="System.Net.Http, Version=4.1.1.3, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL">

Na <HintPath>verdade, ele aponta para a ..\packagespasta do Nuget, ou seja, esta é a versão real instalada pelo Nuget. Depois de implantada, essa versão específica também será restaurada no lado do servidor e tudo deve funcionar com um redirecionamento de ligação.

... e, portanto, o redirecionamento de vinculação deve mencionar esta versão específica da Web.configseguinte forma:

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

Isso corrigiu o problema no meu caso depois de alguns commits no Azure Kudu . O site do Azure finalmente começou sem erros.

O que fiz para corrigir o problema foi remover todas as ligações do web.config e fazer um

Update-Package -reinstall

Isso removeu um monte de amarrações antigas que provavelmente não precisavam estar lá e realmente fez uma boa limpeza.

Encontrei esse erro quando implantei um serviço da web em um de nossos servidores. O projeto era direcionado ao .Net framework 4.7.2, que não estava instalado no servidor. A instalação da estrutura 4.7.2 no servidor corrigiu o problema.

A resposta de Andrei U conduziu à minha salvação. No entanto, o raciocínio não condiz com o meu caso. Para pessoas que estão na mesma situação que eu:

Foi um erro de tempo de execução (não de tempo de construção), onde a construção foi bem-sucedida, mas funcionaria em um computador, mas não no servidor. Solução: - Adicionado pacote System.Net.Http. - Renomear arquivo: C: \ Arquivos de programas (x86) \ Reference Assemblies \ Microsoft \ Framework.NETFramework \ v4.7.2 \ System.Net.Http.dll (por exemplo, renomear para: System.Net.Http.dll.BAK) no construir servidor.

Eu não tinha e ainda não tenho redirecionamentos de montagem para esta dll

Uma solução simples que descobri que faz o downgrade do framework de destino para projetos da web para 4.6.

Eu crio aplicativo cliente e web, cliente tendo .net framework 4.7.1 e web tendo o mesmo e estou enfrentando o mesmo problema, quando eu faço downgrade do framework .net alvo para web, é trabalho para mim.

Depois de lutar com isso por alguns dias, finalmente consegui o problema .Net 4.7.2 / System.Net.Http corrigido para meu projeto. Além de alterar o arquivo * .csproj para direcionar a versão 4.7.2 da estrutura, também tive que atualizar app.config nos projetos de

<supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.6.1" />

para:

<supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.7.2" />

Eu tive o mesmo problema. No final, resolvi alterando o Deploy-FabricApplication.ps1 para algo assim

$binFolder = "$LocalFolder\..\..\..\..\Bin"

$httpDllLocation = "$binFolder\System.Net.Http.dll"
$codeFolder = "$ApplicationPackagePath\[ProjectName].ServicesPkg\Code"
$configFile = "$codeFolder\[ProjectName].Services.exe.config"

Copy-Item $httpDllLocation -Destination $codeFolder 

$appConfig = [xml](cat $configFile)
$appConfig.configuration.runtime.assemblyBinding.dependentAssembly | foreach {

    $name = $_.assemblyIdentity.name
    #Write $name
    if($name -eq 'System.Net.Http')
    {
        Write 'System.Net.Http changed'

        $_.bindingRedirect.newVersion = '4.2.0.0'
    }
}
$appConfig.Save($configFile)

Encontrei um System.Net.Http.dll 4.2.0.0 que é x64. Antes de implantar, este script copia a dll para o diretório do pacote e altera o arquivo de configuração para usar explicitamente esse arquivo. Também escrevi um blog sobre meus problemas de System.Net.Http em http://gertjanvanmontfoort.blogspot.nl/2017/11/systemnethttp-dll-version-problems.html

Não se esqueça de substituir o [ProjectName] pelo nome do seu próprio projeto

Espero que isso ajude, fique à vontade para perguntar

Para mim foi algo realmente estranho. Precisava de horas de depuração depois de descobrir qual era o problema. Isso não aconteceu localmente, mas apenas ao usar jenkins para construir o projeto.

Eu tinha uma pequena biblioteca usando dotnet standart 2.0 e o projeto principal era o projeto WCF que é baseado em .NET normal (o meu era especificamente v4.6.1). Mas na classe de inicialização da biblioteca padrão dotnet, eu tinha um código parecido com este:

public static class CoreModule
{
    public static IServiceCollection AddStaticDataConfiguration(
        this IServiceCollection services, Func<IServiceProvider, IStaticDataConfiguration>  staticDataConfiguration) 
    {  
        services.TryAddSingleton(staticDataConfiguration);
        services.TryAddSingleton<Func<HttpClient>>(x =>
        {
            var configuration = staticDataConfiguration(x);

            return configuration.ClientResolver ?? (() => new HttpClient());
        });
        return services;
    }
}

A interface IStaticDataConfiguration tem a seguinte aparência:

public interface IStaticDataConfiguration
{
    //..... some stuff

    Func<HttpClient> ClientResolver { get; set; }
}  

Essa interface reside dentro da biblioteca padrão dotnet, enquanto a implementação está fora dela (está localizada no projeto WCF).

De fora da biblioteca, eu estava chamando o AddStaticDataConfigurationmétodo abaixo:

serviceCollection.AddStaticDataConfiguration(p =>
{
    var staticDataConfig = p.GetService<IStaticDataConfiguration>();
    return new StaticDataProviderConfiguration
    {
        //...some other stuff
        ClientResolver = () => restRequestFactory.GetInstrumentedClient("StaticDataService") //this returns an HttpClient
    };
});

O problema é que estou passando um Func<HttpClient>de um projeto .NET normal para uma biblioteca padrão do dotnet que, por alguma razão maluca, o padrão do dotnet não gosta e talvez pense que HttpClientvem de classes diferentes, como resultado, lançando System.Net.Http 4.x.x.xuma exceção não encontrada. Quando removido o código para não aceitar um HttpClientde um projeto .NET normal, mas criar um novo funcdentro da própria biblioteca é feliz e está funcionando bem. Espero que isso possa ajudar alguém, já que esse erro está acontecendo por vários motivos :)

Minha solução foi semelhante à de @Raquib. Meu projeto era 4.7.2 e funcionou muito bem no meu PC. Sempre que eu implantava em nosso servidor de desenvolvimento, o problema era mencionado na pergunta. Acontece que a versão .net mais alta no servidor era 4.6.1. Fazer o downgrade do meu projeto para 4.6.1 corrigiu o problema. Atualizar a versão .net do servidor não era uma opção para mim.

Acredito que parte da resposta pode ser encontrada na documentação da Microsoft .

Quando você cria um aplicativo de área de trabalho no Visual Studio voltado para o .NET Framework 4.5.1 ou uma versão posterior, o aplicativo usa o redirecionamento de vinculação automático.

Como aponta a resposta de @Vivek Sharma, removendo:

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

resolveu o problema em 3 desses casos em meu aplicativo. Quando você examina a DLL com Powershell, por exemplo:

 ([system.reflection.assembly]::loadfile("C:\MyApp\bin\System.Net.Sockets.dll")).FullName

Saídas

System.Net.Sockets, Versão = 4.0.0.0

Claramente, um redirecionamento de vinculação para 4.2.0.0não funcionará porque estamos enviando 4.0.0.0para a bandeja.

Também vale a pena verificar o GAC para ver se a montagem também está faltando lá:

 gacutil -l System.Net.Sockets

No meu caso, a versão específica também estava faltando no GAC. Se a DLL estivesse no GAC, ela deveria ter sido encontrada no processo de associação do assembly .

Primeiro exclua do seu sistema de arquivos local:

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

Em seguida, remova todas as referências em Projetos e adicione a referência 4.0.
Isso resolveu meu problema para mim.