Problema extraño con System.Net.Http 4.2.0.0 no encontrado

Tengo un problema extraño que me vuelve loco ...

Tengo un proyecto de biblioteca de clases simple (Full .NET Framework, 4.6.1) con una clase contenedora para la funcionalidad alrededor de Cosmos DB. Por lo tanto, he agregado el paquete NuGet 1.19.1 “Microsoft.Azure.DocumentDB” a este proyecto. Aparte de eso, tengo una referencia al paquete NuGet 10.0.3 "Newtonsoft.Json", así como a un par de paquetes NuGet "Microsoft.Diagnostics.EventFlow. *".

Hasta ahora, todo se compila sin ningún error.

Pero tan pronto como llego a mi clase contenedora, consumida desde un servicio sin estado de Service Fabric simple (Full .NET Framework 4.6.1), e intento ejecutar la siguiente línea de código:

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

Recibo este extraño error en tiempo de ejecución:

System.IO.FileNotFoundException ocurrió HResult = 0x80070002
Message = No se pudo cargar el archivo o ensamblado 'System.Net.Http, Version = 4.2.0.0, Culture = neutral, PublicKeyToken = b03f5f7f11d50a3a' o una de sus dependencias. El sistema no puede encontrar el archivo especificado.
Fuente = StackTrace: en 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 deletedConsistencyLevel )

Excepción interna 1: FileNotFoundException: no se pudo cargar el archivo o ensamblado 'System.Net.Http, Version = 4.0.0.0, Culture = neutral, PublicKeyToken = b03f5f7f11d50a3a' o una de sus dependencias. El sistema no puede encontrar el archivo especificado.

No tengo la menor idea de por qué el ensamblado System.Net.Http no se encuentra en absoluto; incluso hay una referencia de ensamblado en mi proyecto de biblioteca de clases para el ensamblado de .Net Framework “System.Net.Http 4.0.0.0”.

Lo que tampoco entiendo es que existe esta extraña redirección de enlace a 4.2.0.0: ¿de dónde viene esa? Para evitar esto, traté de agregar la siguiente redirección a la app.config del Service Fabric Service (que consume la biblioteca de clases):

Pero todavía no hay diferencia, sigo recibiendo el error en tiempo de ejecución.

¿Alguien tiene una pista? ¿Alguien ha visto tal problema?

Gracias y saludos, OliverB

El problema al que se enfrenta está relacionado con Visual Studio, especialmente 2017, que se envía con System.Net.Http v4.2.0.0. Sin embargo, adoptando la nueva forma en la que cualquier referencia debe hacerse a través de NuGet, la última versión de la System.Net.Httpcual es 4.3.3 contiene la versión dll 4.1.1.2.

El problema es que VS en el tiempo de compilación y también en el tiempo de ejecución ignorará su referencia e intentará hacer referencia a la DLL que conoce.

Como arreglarlo:

• asegúrese de que cualquier referencia a System.Net.Http se haga a través de NuGet
• Errores de tiempo de compilación: cambie la extensión de System.Net.Http.dll (o muévala a otro lugar ... básicamente deshágase de ella) que se envía con VS 2017 ( c:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net461\lib\); si tiene una versión diferente, la ruta será ligeramente diferente, aunque no mucho

• Errores en tiempo de ejecución: agregue una redirección de enlace de ensamblado

Si busca en línea en Google, encontrará algunos problemas abiertos con Microsoft sobre esto, por lo que es de esperar que lo solucionen en el futuro.

Espero que esto ayude.

Actualizar:

Al buscar soluciones permanentes para que este problema funcione en los agentes de compilación, notó que si migra al nuevo modelo NuGet PackageReference (en .csprojnot in packages.config), tiende a funcionar mejor. Aquí hay un enlace a la guía sobre cómo realizar esta actualización: https://docs.microsoft.com/en-us/nuget/reference/migrate-packages-config-to-package-reference

La eliminación de la redirección de enlace funcionó para mí, puede intentar eliminarla:

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

Una adición a la respuesta que @AndreiU ya dio y cómo reproducir los errores de tiempo de ejecución localmente.

Recibí el siguiente error de tiempo de ejecución al implementar en Azure, no localmente.

No se pudo cargar el archivo o ensamblado 'System.Net.Http, Version = 4.2.0.0, Culture = neutral, PublicKeyToken = b03f5f7f11d50a3a' o una de sus dependencias. El sistema no puede encontrar el archivo especificado. "," ExceptionType ":" System.IO.FileNotFoundException "," StackTrace ":" en Company.Project.Service.CompanyIntegrationApiService..ctor (Uri baseAddress) \ r \ n en Company.Project .BackOffice.Web.Controllers.OrderController..ctor () en C: \ proyectos \ empresa-proyecto \ src \ Company.Project.BackOffice.Web \ Controllers \ Order \ OrderController.cs: línea 30 \ r \ n en lambda_method ( Closure) \ r \ n en System.Web.Http.Dispatcher.DefaultHttpControllerActivator.Create (solicitud HttpRequestMessage, HttpControllerDescriptor controllerDescriptor, Type controllerType) "}} Culture = neutral, PublicKeyToken = b03f5f7f11d50a3a 'o una de sus dependencias. El sistema no puede encontrar el archivo especificado. "," ExceptionType ":" System.IO.FileNotFoundException "," StackTrace ":" en Company.Project.Service.CompanyIntegrationApiService..ctor (Uri baseAddress) \ r \ n en Company.Project .BackOffice.Web.Controllers.OrderController..ctor () en C: \ proyectos \ empresa-proyecto \ src \ Company.Project.BackOffice.Web \ Controllers \ Order \ OrderController.cs: línea 30 \ r \ n en lambda_method ( Closure) \ r \ n en System.Web.Http.Dispatcher.DefaultHttpControllerActivator.Create (solicitud HttpRequestMessage, HttpControllerDescriptor controllerDescriptor, Type controllerType) "}} Culture = neutral, PublicKeyToken = b03f5f7f11d50a3a 'o una de sus dependencias. El sistema no puede encontrar el archivo especificado. "," ExceptionType ":" System.IO.FileNotFoundException "," StackTrace ":" en Company.Project.Service.CompanyIntegrationApiService..ctor (Uri baseAddress) \ r \ n en Company.Project .BackOffice.Web.Controllers.OrderController..ctor () en C: \ proyectos \ empresa-proyecto \ src \ Company.Project.BackOffice.Web \ Controllers \ Order \ OrderController.cs: línea 30 \ r \ n en lambda_method ( Closure) \ r \ n en System.Web.Http.Dispatcher.DefaultHttpControllerActivator.Create (solicitud HttpRequestMessage, HttpControllerDescriptor controllerDescriptor, Type controllerType) "}}

Cuando comencé a buscar ensamblajes, pude ver que mi proyecto web y mi proyecto de servicio apuntaban a diferentes versiones de System.Net.Http.

Proyecto web:

Proyecto de servicio:

Es fácil pensar que esto se debe a una discrepancia en las versiones, pero la clave aquí es mirar el error The system cannot find the file specified..

Al observar la propiedad de la ruta, podemos ver que el proyecto web tiene como objetivo un ensamblado .Net Framework mientras que el servicio tiene como objetivo un ensamblado de Visual Studio 2017. Dado que el servidor no tiene Visual Studio 2017 instalado, se producirá el error de tiempo de ejecución.

Ruta web:

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

Ruta de servicio:

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

Algo tan simple como la creación Copy Localde truepuede solucionar el problema, sin embargo, no en todos los casos.

Para reproducir el error en su máquina local, simplemente elimine lo necesario System.Net.Http.dllde la carpeta específica de Visual Studio. Esto le dará el error de tiempo de ejecución y probablemente algunos errores de compilación. Después de que estos estén arreglados, todo debería funcionar, al menos a mí me funcionó.

Si ha instalado System.Net.Httpmediante, NuGetcompruebe qué ensamblaje se utiliza mirando la .csprojversión. System.Net.Http 4.3.4da el siguiente montaje, por ejemplo:

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

Si usa un servidor de compilación como Jenkins, TeamCity o AppVeyor, el tiempo de ejecución que falta también .dllpuede existir allí. En este caso, es posible que no sirva de ayuda usar la versión NuGet de System.Net.Http o eliminar .dlllocalmente lo que falta . Para solucionar este error mire la versión que no se encuentra y la específica PublicKeyToken. Después de eso, cree un redireccionamiento vinculante en cualquiera de los dos Web.configo App.configdependiendo de su proyecto. En mi caso, me gustaría usar 4.0.0.0 en su lugar:

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

Un buen hilo de Github sobre el problema:

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

Acabo de instalar System.Net.Httpusando NuGet. Puedes agarrarlo aqui:

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

El ASP.NET MVCproyecto en el que estoy trabajando tiene objetivos .NET 4.6.1. Funciona perfectamente en mi máquina mientras se depura IIS Expresscon Visual Studio 2019.

El problema ocurrió al intentar ejecutar la aplicación implementada en Azure. Recibía este error:

No se pudo cargar el archivo o ensamblado 'System.Net.Http, Version = 4.2.0.0, Culture = neutral, PublicKeyToken = b03f5f7f11d50a3a' o una de sus dependencias.

Lo que realmente funcionó en mi caso fue abrir el archivo .csproj y buscar System.Net.Httpcomo en la siguiente captura de pantalla ...

Vea que el .csprojarchivo tenga la versión 4.1.1.3:

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

En <HintPath>realidad, apunta a la ..\packagescarpeta de Nuget, es decir, esta es la versión real instalada por Nuget. Una vez implementada, esta versión específica también se restaurará en el lado del servidor y todo debería funcionar con una redirección de enlace.

... por lo que la redirección de enlace debe mencionar esta versión específica de Web.configesta manera:

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

Esto solucionó el problema en mi caso después de un par de confirmaciones con Azure Kudu . El sitio web de Azure finalmente comenzó sin errores.

Lo que hice para solucionar el problema fue eliminar todos los enlaces de web.config e hice un

Update-Package -reinstall

Esto eliminó un montón de encuadernaciones viejas que probablemente no necesitan estar allí y realmente hizo una buena limpieza.

Encontré este error cuando implementé un servicio web en uno de nuestros servidores. El proyecto tenía como objetivo .Net framework 4.7.2, que no estaba instalado en el servidor. La instalación del marco 4.7.2 en el servidor corrigió el problema.

La respuesta de Andrei U condujo a mi salvación. Sin embargo, el razonamiento no coincidía con mi caso. Para las personas que se encuentran en el mismo escenario que yo:

Fue un error de tiempo de ejecución (no tiempo de compilación), donde la compilación tuvo éxito, pero funcionaría en una computadora, pero no en el servidor. Solución: - Se agregó el paquete System.Net.Http. - Cambiar el nombre del archivo: C: \ Archivos de programa (x86) \ Reference Assemblies \ Microsoft \ Framework.NETFramework \ v4.7.2 \ System.Net.Http.dll (por ejemplo, cambiar el nombre a: System.Net.Http.dll.BAK) en el construir servidor.

No tenía y todavía no tengo redireccionamientos de ensamblado para este dll

Encontré una solución simple que rebaja el marco de destino para el proyecto web a 4.6.

Creo un cliente y una aplicación web, el cliente tiene .net framework 4.7.1 y la web tiene lo mismo y me enfrento al mismo problema, cuando degrado el framework .net de destino para web, me funciona.

Después de luchar con esto durante un par de días, finalmente solucioné el problema .Net 4.7.2 / System.Net.Http para mi proyecto. Además de cambiar el archivo * .csproj para apuntar a la versión 4.7.2 del marco, también tuve que actualizar app.config en los proyectos de

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

a:

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

Yo tuve el mismo problema. Al final lo resolví cambiando Deploy-FabricApplication.ps1 a algo como esto

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

Encontré un System.Net.Http.dll 4.2.0.0 que es x64. Antes de implementar esta secuencia de comandos, copia la dll en el directorio del paquete y cambia el archivo de configuración para usar explícitamente este archivo. También escribí un blog sobre mis problemas de System.Net.Http en http://gertjanvanmontfoort.blogspot.nl/2017/11/systemnethttp-dll-version-problems.html

No olvide reemplazar [ProjectName] con su propio nombre de proyecto

Espero que esto ayude, no dude en preguntar

Para mí fue algo realmente extraño. Horas necesarias de depuración después de encontrar cuál era el problema. No sucedió localmente, sino solo cuando se usó jenkins para construir el proyecto.

Tenía una pequeña biblioteca que usaba dotnet standart 2.0 y el proyecto principal era el proyecto WCF, que se basa en .NET normal (el mío era específicamente v4.6.1). Pero en la clase de inicio de la biblioteca estándar de dotnet tenía un código que se veía así:

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

La interfaz IStaticDataConfiguration se ve a continuación:

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

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

Esta interfaz reside dentro de la biblioteca estándar de dotnet mientras que la implementación está fuera de ella (se encuentra en el proyecto WCF).

Desde fuera de la biblioteca, estaba llamando al AddStaticDataConfigurationmétodo como se muestra a continuación:

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

El problema es que estoy pasando Func<HttpClient>de un proyecto .NET normal a una biblioteca estándar de dotnet que, por alguna loca razón, no le gusta a dotnet standart y tal vez piense HttpClientque proviene de diferentes clases, como resultado arrojando System.Net.Http 4.x.x.xuna excepción no encontrada. Cuando se elimina el código para no aceptar un HttpClientproyecto de .NET normal, pero crear uno nuevo funcdentro de la biblioteca, es feliz y funciona bien. Espero que esto pueda ayudar a alguien más, ya que este error ocurre por muchas razones :)

Mi solución fue similar a la de @ Raquib. Mi proyecto era 4.7.2 y funcionó bien en mi PC. Siempre que lo implementaba en nuestro servidor de desarrollo, obtenía el problema mencionado en la pregunta. Resulta que la versión .net más alta en el servidor era 4.6.1. La degradación de mi proyecto a 4.6.1 solucionó el problema. Actualizar la versión .net del servidor no era una opción para mí.

Creo que parte de la respuesta se puede encontrar en la documentación de Microsoft .

Cuando crea una aplicación de escritorio en Visual Studio que tiene como destino .NET Framework 4.5.1 o una versión posterior, la aplicación usa la redirección de enlace automática.

Como señala la respuesta de @Vivek Sharma, eliminar:

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

resolvió el problema en 3 de estos casos en mi aplicación. Cuando examina la DLL con Powershell, por ejemplo:

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

Salidas

System.Net.Sockets, versión = 4.0.0.0

Claramente, una redirección de enlace a 4.2.0.0no va a funcionar porque estamos enviando 4.0.0.0una salida al contenedor.

También vale la pena verificar el GAC para ver si el ensamblado también falta allí:

 gacutil -l System.Net.Sockets

En mi caso, la versión particular también faltaba en el GAC. Si la DLL estaba en el GAC, entonces debería haberse encontrado en el proceso de enlace de ensamblado .

Primero elimine de su sistema de archivos local:

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

Luego elimine todas las referencias en Proyectos y agregue la referencia 4.0.
Esto me resolvió mi problema.