c# - microsoft - nuget package manager visual studio 2017

System.*Problemas de referencia al introducir la dependencia NETStandard.Library (1)

En la plantilla de proyecto predeterminada, System.Net.Http se agrega al proyecto como una referencia, no como un paquete nuget.

En ambas soluciones (4.6.1 y 4.7.1):

Project ClassLibrary tiene una dependencia en System.Net.Http como un paquete nuget.
Project ConsoleApp1 depende de System.Net.Http como una simple referencia de .NET Framework

Por lo tanto, el problema no está relacionado con la versión de Target Framework.

Para solucionar el problema, agregue la misma versión de System.Net.Http como un paquete nuget a todos los proyectos (donde se usa).

Haga clic derecho en la solución en el Explorador de soluciones y elija Manage NuGet Packages for Solution...
Cambiar a la pestaña Installed
Busque System.Net.Http en la lista, selecciónelo.
Compruebe el estado actual:

Instale la misma versión del paquete (4.3.0 en su caso) en el proyecto ConsoleApp1 .
Compruebe el resultado:

Reconstruye la solución.

Hecho.

Además, es una buena práctica tener versiones de paquete consolidadas en su solución. En su lugar, podría tener conflictos de versión durante el tiempo de compilación. O, lo que es peor, el error de tiempo de ejecución como MethodNotFound debido a la redirección de enlace a otra versión de la dependencia.

El motivo del problema con System.Net.Http se describe aquí: Broken System.Net.Http 4.1.1-4.3.0 post-mortem en la sección ¿Cómo prevenir esta situación en el futuro? 2.1

Como resultado, identificamos 2 paquetes OOB problemáticos, que no son nodos hoja en la plataforma en sí, y tienen dependencia de la plataforma en ellos: System.Net.Http y System.IO.Compression.

Significa que la misma biblioteca System.Net.Http se envía dentro de .NET Framework y como paquete de nuget OOB (fuera de banda). Y algunos paquetes nuget podrían hacer referencia a su versión. Y aquí viene el problema que describí al principio.

Por lo tanto, no tiene que arreglar las referencias a todas las bibliotecas de System.* . Solo para estos dos: System.Net.Http y System.IO.Compression .

En una gran solución con 52 proyectos (todos net462), la última versión de algunas de nuestras dependencias ahora solo se construye para el estándar NET. Por lo tanto, dependen del paquete NETStandard.Library que a su vez arrastra muchos otros paquetes de la versión 4.3.x de System.* Que normalmente se encuentran en .NET Framework.

Como resultado, algunos proyectos hacen referencia a las bibliotecas de System.* De la carpeta de paquetes, mientras que otros hacen referencia a las bibliotecas de System.* De .NET Framework.

Esto causa el problema de tiempo de ejecución conocido, fe:

Mensaje: System.IO.FileLoadException: No se pudo cargar el archivo o ensamblaje ''System.Net.Http, Versión = 4.1.1.2, Culture = neutral, PublicKeyToken = b03f5f7f11d50a3a'' o una de sus dependencias. La definición del manifiesto del ensamblaje localizado no coincide con la referencia del ensamblaje. (Excepción de HRESULT: 0x80131040)

NETStandard.Library las dependencias de los paquetes NETStandard.Library , podemos ver que el mismo problema también existe en estos paquetes:

Sistema.Colecciones. *
System.ComponentModel. *
Sistema.consola
System.Globalization. *
System.IO. *
System.Linq. *
System.Net. *
System.ObjectModel
System.Reflection. *
System.Resources.ResourceManager
System.Runtime. *
System.Text. *
Sistema.Threading. *
System.Xml. *

Normalmente esto se soluciona instalando el mismo paquete en los otros proyectos, pero estamos tratando con muchos proyectos y muchos paquetes aquí y no quiero agregar ciegamente todas esas dependencias a los 52 proyectos.

Esto me hizo preguntarme si alguien sabe una manera fácil de recuperarse de esta situación y hacer que todos los proyectos hagan referencia al paquete / DLL correcto de la carpeta de paquetes de NuGet si actualmente usan el NET Framework interno.

Una solución VS simple para net462 y net471 que demuestra el problema se puede encontrar here