¿Por qué my.NET ¿El paquete NuGet estándar activa tantas dependencias?

No has hecho nada malo, se espera que esto suceda. Si no desea nada más que agregar su propia DLL a un nuevo proyecto de. NET Framework, debe apuntar a. NET Standard 2.0 para su biblioteca espere una versión de. NET Framework que admita de forma nativa tanto la API como las versiones de ensamblado, que será 4.7.2 (mientras que. NET Framework 4.7.1 admite todas las API, hubo errores con la forma en que se versionan algunos ensamblados y, por lo tanto, las herramientas (VS 2017 15.5+) agregarán ensamblajes para arreglar eso).

Lo que está viendo son los efectos secundarios de cómo se construye.NET Standard y se implementa el soporte para los frameworks soportados. Esto también es diferente según la versión estándar de. NET a la que se dirige y las herramientas utilizadas para hacer referencia al paquete de la biblioteca.

En.NET Standard NETStandard.Library que a su vez hace referencia a paquetes adicionales (System.*). Esos paquetes contienen los ensamblados de referencia que componen el estándar". NET Contract " - un conjunto de API y los nombres de ensamblado + versiones.

Cuando una aplicación hace referencia al paquete NuGet que crea para.NET Standard 1.0-1.6, estos paquetes individuales no traen los ensamblados de referencia, sino más bien ensamblados de implementación para el marco al que se dirige la aplicación.

Para.NET Core, estos coinciden con los ensamblados que ya forman parte del tiempo de ejecución, por lo que los archivos DLL no terminarán junto a la aplicación construida. Sin embargo, esto cambió cuando se lanzó un nuevo conjunto de paquetes para. NET Core 1.1 (NETStandard.Library versión 1.6.1). Esto dio lugar a que las aplicaciones creadas para.NET Core 1.0 terminaran recibiendo ensamblados de implementación más nuevos que estaban destinados a ser incluidos en. NET Core 1.1 (afortunadamente, 1.1 se convirtió en la versión de "soporte a largo plazo", ya que provocó una discusión sobre qué ensamblados son parte de la promesa de LTS).

En. NET Framework estas bibliotecas (con algunas excepciones como System.Net.Http) no hacen mucho , solo reenvían a los ensamblajes del sistema. Así, por ejemplo, el "contrato" define que System.Object se define en un ensamblado System.Runtime.dll. Por lo tanto, el archivo System.Runtime.dll con el que termina en una aplicación de.NET Framework contiene un System.Runtime.dll que contiene el tipo reenviar a mscorlib.dll de. NET Framework. . NET Core ya contiene un System.Runtime.dll diferente que hace algo diferente para esa plataforma. Este mecanismo permite que un único archivo DLL funcione en ambas plataformas ya que esos reenvíos de tipo e implementaciones adicionales aseguran el mismo "contrato" (tipos + ensamblajes + versiones ensambladas) trabajando en ambas implementaciones.

. NET Standard 2.0 tenía como objetivo reducir el número de paquetes y DLLs que son necesarios y también eliminar las actualizaciones que requieren NETStandard.Library cada vez que se lanza una nueva versión de. NET Core.

Así que para.NET Standard 2.0 y. NET Core 2.0, el paquete NETStandard.Library solo trae ensamblados de referencia para compilar código a un proyecto, pero el paquete NuGet resultante ya no depende de este paquete. Así que cuando creas una segmentación de biblioteca . NET Standard 2.0 y publíquelo, no tendrá dependencias NuGet (a menos que agregue otras adicionales).

La lógica de lo que las "bibliotecas de soporte" deben traer cuando se consume una biblioteca estándar.NET se trasladó a las herramientas que se utilizan durante la compilación. Por lo tanto, cuando se agrega una biblioteca que contiene una referencia a netstandard.dll a un proyecto de.NET Framework, las herramientas agregarán las DLL de soporte necesarias basadas en la versión de. NET Framework que se esté utilizando. Esto se hizo para. NET Estándar 2.0, así como . NET Standard 1.5 + desde. NET Framework 4.6.1 se hizo compatible retroactivamente con. NET Standard 2.0 (anteriormente era 1.4) a través de este tipo de archivos DLL. La misma herramienta también se asegura de que incluso si los paquetes de NuGet se introducen de alguna manera en un proyecto de aplicación de este tipo, cualquier biblioteca de implementación estándar de.NET introducida a través de NuGet se elimine de la compilación. Por lo tanto, si hace referencia a un paquete NuGet. NET Standard 1.0 que se construyó cuando se lanzó. NET Core 1.0, todas sus dependencias NuGet son recortado y obtiene las bibliotecas de soporte enviadas con las herramientas de compilación en su lugar.

La idea era que. NET Framework 4.7.1 contendría todos los ensamblados necesarios "bandeja de entrada" para que un netstandard.dll, System.Runtime.dll etc. son parte de. NET Framework y cualquier archivo DLL. NET Standard 1.0-2.0 "simplemente funcionaría", el problema era que estos archivos dll "bandeja de entrada" tenían un número de versión demasiado bajo para algunos ensamblados, por lo que las bibliotecas no podían cargarse - esto se solucionó cambiando las herramientas nuevamente para incluir archivos DLL con números de versión más altos como bibliotecas de soporte que a su vez reenvían a los ensamblados de.NET Framework "inbox". Está previsto que esto se solucione en. NET Framework 4.7.2.