.net - studio - net standard 2.0 download

¿Por qué mi paquete.NET Standard NuGet desencadena tantas dependencias? (3)

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

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

En .NET Standard <2.0, hace referencia al NETStandard.Library que a su vez hace referencia a paquetes adicionales ( System.* ). Esos paquetes contienen los ensamblajes de referencia que conforman el "Contrato estándar de .NET", un conjunto de API y los nombres de ensamblajes + versiones.

Cuando una aplicación hace referencia al paquete NuGet que crea para .NET Standard 1.0-1.6, estos paquetes individuales no incorporan los ensamblajes de referencia sino los ensamblajes de implementación para el marco al que apunta la aplicación.

Para .NET Core, estos coinciden con los ensamblados que ya forman parte del tiempo de ejecución para que los archivos DLL no terminen junto a la aplicación creada. 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 como resultado que las aplicaciones creadas para .NET Core 1.0 terminaran obteniendo nuevos ensamblados de implementación que debían incluirse 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é ensambles 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 ensamblados del sistema. Así, por ejemplo, el "contrato" define que System.Object se define en un ensamblado System.Runtime.dll . Entonces, el archivo System.Runtime.dll el que termina en una aplicación .NET Framework contiene un System.Runtime.dll que contiene reenvío de tipo a mscorlib.dll .NET Framework. .NET Core ya contiene un System.Runtime.dll diferente que hace algo diferente para esa plataforma. Este mecanismo permite que un solo archivo DLL funcione en ambas plataformas, ya que esos tipos de reenvío e implementaciones adicionales aseguran que el mismo "contrato" (tipos + ensamblados + versiones de ensamblaje) funcione en ambas implementaciones.

.NET Standard 2.0 tenía como objetivo reducir la cantidad de paquetes y archivos DLL necesarios y también eliminar las actualizaciones necesarias de NETStandard.Library cada vez que se NETStandard.Library una nueva versión de .NET Core.

Entonces, 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. Entonces, cuando cree una biblioteca dirigida a .NET Standard 2.0 y la publique, no tendrá dependencias de NuGet (a menos que agregue otras adicionales).

La lógica de qué "bibliotecas de soporte" incorporar al consumir una biblioteca estándar .NET se movió a las herramientas que se utilizan durante la compilación. Entonces, cuando una biblioteca que contiene una referencia a un netstandard.dll se agrega a un proyecto de .NET Framework, las herramientas agregarán las DLL de soporte necesarias según la versión de .NET Framework que se esté utilizando. Esto se hizo para .NET Standard 2.0 y para .NET Standard 1.5+ ya que .NET Framework 4.6.1 se hizo retroactivamente compatible con .NET Standard 2.0 (era 1.4 anteriormente) a través de este tipo de archivos DLL. Las mismas herramientas también aseguran que incluso si los paquetes NuGet se incorporan de alguna manera a un proyecto de aplicación de este tipo, las bibliotecas de implementación de .NET Standard introducidas a través de NuGet se eliminan de la compilación. Entonces, si hace referencia a un paquete NuGet de .NET Standard 1.0 que se creó cuando se lanzó .NET Core 1.0, todas sus dependencias de NuGet se recortan y obtiene las bibliotecas de soporte incluidas con las herramientas de compilación.

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. sean parte de .NET Framework y cualquier archivo DLL .NET Standard 1.0-2.0 "simplemente funciona", el problema era que estos archivos dll de "bandeja de entrada" tenían un número de versión demasiado bajo para algunos ensamblados, por lo que las bibliotecas no se cargaban; 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 avanza a los ensamblados de "Bandeja de entrada" .NET Framework. Se planea solucionarlo en .NET Framework 4.7.2.

He estado jugando con un proyecto .NET Standard y NuGet. Tengo un proyecto que funciona y lo he subido a NuGet.org . Mi proyecto apunta a .NET Standard 1.3, que debería ser compatible con .NET Framework 4.6 y .NET Core 1.0.

Pero cuando intenté agregar mi proyecto (a través de NuGet) a un nuevo proyecto de .NET Framework 4.6, ¡las dependencias se resolvieron en 47 paquetes! Todas son bibliotecas del sistema y parecen ser dependencias de Microsoft.NETCore.Platforms o NETStandard.Library 1.6.1. ( Resumen de la salida PM completa ) .

Mi proyecto solo importa ( using ) un puñado de bibliotecas, ninguna de las cuales agregué manualmente; es decir, todas son bibliotecas que "vinieron con" .NET Standard. Estas bibliotecas son:

Sistema
System.Text
Reflexión del sistema
System.Linq
System.Collections.Generic;

La cuestión es que decidí hacer que mi proyecto apunte a .NET Standard porque quería que funcionara perfectamente en .NET Framework y .NET Core. Pensé que el objetivo de Standard era establecer un nivel mínimo de compatibilidad. Por extensión, supongo que supuse (quizás erróneamente) que bibliotecas como System.Console estarían disponibles automáticamente en Core o Framework.

No noté nada como esto cuando probé mi proyecto estándar como una dependencia en un proyecto Framework y Core dentro de la misma solución, por lo que sospecho que esto podría ser algo NuGet.

¿Qué está pasando realmente aquí? ¿Y cómo puedo hacer que mi biblioteca estándar .NET esté disponible en NuGet sin una gran lista de dependencias?

¿Es un problema con la forma en que he especificado mi paquete NuGet? ¿O fundamentalmente he entendido mal algo?

Si está en .NET 4.6 y está tratando de descubrir cuáles necesita implementar, busque en su archivo CSPROJ /System. (no es una expresión regular): son los que están en los paquetes que deben copiarse con su aplicación, el resto deben ser archivos DLL de framework.

Para probar esta teoría, deshágase de ellos en su compilación local y ejecútelos para asegurarse de que la versión implementada no se rompa ...

En la carpeta bin, haga dir /b System*.dll > textfile.txt para obtener una lista de las DLL.
insertó "DEL" delante de todos los nombres,
También encontré Microsoft.Win32.Primitives.dll y netstandard.dll que tampoco eran necesarios en 4.6.
y guárdelo como un archivo .CMD - uh, no en la carpeta bin, ¿está bien?
agréguelo como un proceso posterior a la compilación. $(ProjectDir)DeleteSuperfluousSystemDlls.cmd

Me encantaría salir de .NET 4.6, pero AutoCAD se rompe mal cuando el marco es demasiado moderno para ello.

editar...

Aquí hay algo de copiar y pegar ...

Paso 1 - en tu archivo CSPROJ ...

<UsingTask TaskName="ExecAsync" TaskFactory="CodeTaskFactory" AssemblyFile="$(MSBuildToolsPath)/Microsoft.Build.Tasks.v4.0.dll"> <ParameterGroup>  <FilePath ParameterType="System.String" Required="true" />  <Arguments ParameterType="System.String" Required="true" /> </ParameterGroup> <Task> <Code Type="Fragment" Language="cs"><![CDATA[ System.Diagnostics.ProcessStartInfo processStartInfo = new System.Diagnostics.ProcessStartInfo(FilePath, Arguments); processStartInfo.UseShellExecute = true; System.Diagnostics.Process.Start(processStartInfo); ]]></Code> </Task> </UsingTask> <Target Name="AfterBuild"> <ExecAsync FilePath="$(ProjectDir)/Deployment/DeleteSuperfluousSystemDlls.cmd" Arguments="$(TargetDir)" /> </Target>

Paso 2. El archivo por lotes ...

Edite la lista creada por dir /b System*.dll > textfile.txt para parecerse mucho a

del %1Microsoft.Win32.Primitives.dll del %1netstandard.dll del %1System.AppContext.dll del %1System.Collections.Concurrent.dll del %1System.Collections.dll del %1System.Collections.NonGeneric.dll del %1System.Collections.Specialized.dll del %1System.ComponentModel.dll

pero no olvide eliminar los que realmente necesita para que no se eliminen.

También me encontré con este problema también. La blog.tdwright.co.uk/2017/11/21/… que vinculó en un comentario a la respuesta de Martin Ullrich me llevó a una solución que funcionó para mí: usar la focalización múltiple NuGet . Cambiando:

<TargetFramework>netstandard1.0</TargetFramework>

<TargetFrameworks>netstandard1.0;netstandard2.0;net45</TargetFrameworks>

en el archivo del proyecto .csproj . Esto hace que el proyecto se construya por separado para cada marco de destino y el paquete NuGet resultante solo depende de NETStandard.Library para netstandard1.0 . Dado que NuGet elige los binarios net45 para cualquier versión completa de .NET Framework , esto evita las dependencias innecesarias al instalar el paquete.