dll - La referencia del paquete System.Net.Http NuGet 4.3.0 genera System.IO.FileLoadException en System.Diagnostics.DiagnosticSource ver 4.0.0.0 reference

nuget-package .net-4.6.2

Question

Descripción del problema:

Un proyecto de biblioteca compartida "shared.dll" hace referencia al paquete System.Net.Http NuGet 4.3.0. La aplicación que hace referencia a "shared.dll" falla con

System.IO.FileLoadException

No se pudo cargar el archivo o ensamblado ''System.Diagnostics.DiagnosticSource, Version = 4.0.0.0, Culture = neutral, PublicKeyToken = cc7b13ffcd2ddd51'' o una de sus dependencias. La definición del manifiesto del ensamblaje ubicado no coincide con la referencia de ensamblaje. (Excepción de HRESULT: 0x80131040)

en System.Net.Http.WinHttpHandler.SendAsync (...)

Después de investigar este problema, llegamos a la siguiente causa del error anterior:

• La página de información del paquete para System.Net.Http v 4.3.0 establece la dependencia en System.Diagnostics.DiagnosticSource v 4.3.0 o superior. Este paquete se descarga automáticamente cuando se hace referencia a System.Net.Http v 4.3.0 desde el proyecto.
• El paquete NuGet de System.Net.Http v 4.3.0 de hecho incluye System.Net.Http.dll v 4.1.1.0 (desde el 8 de enero de 2017).
• El paquete NuGet de System.Diagnostics.DiagnosticSource v 4.3.0 de hecho incluye System.Diagnostics.DiagnosticSource v 4.0.1.0 (desde el 8 de enero de 2017).
• System.Net.Http ver 4.1.1.0 references System.Diagnostics.DiagnosticSource v. 4.0.0.0
• System.Diagnostics.DiagnosticSource v. 4.0.0.0 no es una coincidencia exacta con v el dll descargado v 4.0.1.0.
• Cuando la versión de una referencia de biblioteca fuertemente nombrada no coincide exactamente, el tiempo de ejecución de .NET aún intenta encontrar el ensamblado al que se hace referencia. Si no puede: se genera la excepción de carga de la biblioteca. Ver también el siguiente comentario

Hay un par de soluciones:

1. Opción app.config: declare las versiones compatibles (¿hasta dónde podemos llegar con eso?) con la redirección de enlace en app.config para cualquier aplicación de referencia "shared.dll".

<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="System.Diagnostics.DiagnosticSource" publicKeyToken="cc7b13ffcd2ddd51" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-4.0.1.0" newVersion="4.0.1.0" />
</dependentAssembly>
</assemblyBinding>

2. Forzar System.Diagnostics.DiagnosticSource.dll a la versión 4.0.0.0: Agregue la referencia de NuGet a System.Diagnostics.DiagnosticSource v. 4.0.0.0 a los proyectos que hacen referencia a System.Net.Http para adelantarse a la descarga automática de la versión de dll 4.0.1.0. Esta opción pierde la capacidad de actualizar automáticamente la dependencia de NuGet, pero hace que la implementación de las aplicaciones sea menos configurada.

Sin embargo, existe la sensación de que la solución correcta del problema radica en corregir las incoherencias de paquetes NuGet antes mencionadas por parte de los propietarios del paquete. Cuando se corrigió en el origen, no se necesitaría ninguna solución para el código de consumo del paquete System.Net.Http.

Preguntas:

1. ¿Por qué el paquete System.Net.Http v 4.3.0 contiene errores de System.Net.Http.dll v 4.1.1 mientras que hay una versión anterior del paquete 4.1.1?
2. ¿Deberíamos seguir adelante con cualquiera de las 2 soluciones alternativas mencionadas anteriormente?
3. ¿Cuál es mejor?
4. O: ¿hay alguna otra solución al problema?
5. O bien, ¿hay una actualización inminente de los paquetes NuGet que solucione la incoherencia?

Gracias.

Answer 1

Siento que sería correcto utilizar mi propia pregunta porque el 99% de la respuesta ya está allí.

El equipo de desarrollo de github / corefx reconoció que la resolución de este problema sería un efecto secundario de otra corrección de problemas conocida por la naturaleza de eliminar la referencia a System.Diagnostics.DiagnosticSource.dll del proyecto System.Net.Http.

Hasta entonces: cualquiera de las dos soluciones provistas está bien para usar en función de las preferencias personales.

Answer 2

Resolví este problema instalando System.Net.Http (versión 4.3.1) desde NuGet.