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 de manifiesto del ensamblado ubicado no coincide con la referencia del ensamblado. (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 paraSystem.Net.Http v 4.3.0 declara dependencia deSystem.Diagnostics.DiagnosticSource v 4.3.0 o arriba. Este paquete se descarga automáticamente cuando se hace referencia a System.Net.Http v 4.3.0 desde el proyecto.De hecho, el paquete NuGet de System.Net.Http v 4.3.0 incluye System.Net.Http.dll v 4.1.1.0 (a partir del 8 de enero de 2017).De hecho, el paquete NuGet de System.Diagnostics.DiagnosticSource v 4.3.0 incluye System.Diagnostics.DiagnosticSource v 4.0.1.0 (a partir del 8 de enero de 2017).System.Net.Http ver 4.1.1.0 referencias System.Diagnostics.DiagnosticSource v. 4.0.0.0System.Diagnostics.DiagnosticSource v. 4.0.0.0 no coincide exactamente con el dll descargado v 4.0.1.0.Cuando la versión de una referencia de biblioteca con un nombre fuerte 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. Vea también lo siguienteobservación

Hay un par de soluciones:

Opción app.config: declarar versiones compatibles (¿hasta dónde deberíamos llegar con eso?) conredireccionamiento vinculante en app.config paraalguna "shared.dll": aplicación de referencia.

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

Forzar System.Diagnostics.DiagnosticSource.dll a la versión 4.0.0.0: agregue la referencia NuGet a System.Diagnostics.DiagnosticSource v. 4.0.0.0 a los proyectos que hacen referencia a System.Net.Http para evitar la descarga automática de la versión dll 4.0.1.0. Esta opción pierde la capacidad de actualizar automáticamente la dependencia NuGet, pero hace que la implementación de las aplicaciones no tenga configuración.

Sin embargo, existe una sensación persistente de que la solución adecuada del problema radica en corregir las inconsistencias de los paquetes NuGet antes mencionados por parte de los propietarios del paquete. Cuando se arregla en la fuente, no se requerirá una solución alternativa para el código que consume el paquete System.Net.Http.

Preguntas:

¿Por qué el paquete System.Net.Http v 4.3.0 contiene desajuste System.Net.Http.dll v 4.1.1 mientras que hay una versión anterior exacta del paquete 4.1.1?¿Deberíamos seguir adelante con cualquiera de las 2 soluciones mencionadas anteriormente?¿Cuál es mejor?O: ¿Hay otra solución al problema?O: ¿Existe una actualización inminente de los paquetes NuGet que solucione la inconsistencia?

Gracias.