0
372
Vistas¿Cómo crear un paquete .NET Standard NuGet con dependencias mínimas en VS 2017?
Actualmente estoy en el proceso de migrar un proyecto de biblioteca para admitir .NET Standard 1.1 con Visual Studio 2017.
Tenía la esperanza de lanzar el proyecto como un único paquete NuGet que podría apuntar tanto a .NET Framework 4.5+ como a .NET Core, UWP, etc.
Sin embargo, cuando intento instalar el paquete resultante en proyectos de .NET Framework, se genera una enorme lista de dependencias de paquetes que contiene todos los paquetes definidos en el estándar .NET (ver más abajo):
Entiendo que estos son todos los ensamblados definidos como parte de la especificación .NET Standard 1.1. Sin embargo, mi proyecto específico en realidad requiere solo un pequeño subconjunto de ellos, y esta lista de dependencias será extremadamente confusa para cualquiera que instale el paquete en sus proyectos.
Traté de seguir la respuesta a una pregunta similar donde la recomendación era cambiar la especificación del proyecto para hacer referencia solo a las dependencias exactas requeridas por el proyecto.
Sin embargo, la respuesta estaba en el contexto del antiguo formato project.json, que ahora ha sido reemplazado por el nuevo formato .csproj en VS 2017. Intenté eliminar la dependencia del metapaquete .NET Standard 1.1 eliminando <TargetFramework> directiva pero solo logré romper la compilación y no pude encontrar ninguna forma de agregar específicamente solo las dependencias que se necesitaban.
La promesa de mover las bibliotecas a .NET Standard para lograr la máxima compatibilidad con la plataforma es extremadamente atractiva, pero ¿cuál es la forma recomendada de estructurar las dependencias de modo que los proyectos que tienen como objetivo el .NET Framework "clásico" no encuentren sus proyectos "contaminados" por todas estas dependencias?
3 Respuestas
Responde la pregunta0
Cambie <TargetFramework> a <TargetFrameworks> y agréguele ;net45 . Todavía obtiene una única salida del paquete NuGet, pero ahora solo obtendrá las dependencias adicionales si tiene como objetivo una aplicación .NET core (que ya tendrá las dependencias).
0
Primero, me gustaría señalar que esto es principalmente un problema de tiempo de diseño y no afecta las aplicaciones resultantes ni la portabilidad de sus bibliotecas:
En el pasado, recomendábamos a los desarrolladores que no hicieran referencia al metapaquete (
NETStandard.Library) de los paquetes de NuGet, sino que hicieran referencia a paquetes individuales, comoSystem.RuntimeySystem.Collections. La razón fue que pensamos en el metapaquete como una forma abreviada de un grupo de paquetes que eran los bloques de construcción atómicos reales de la plataforma .NET. La suposición era: podríamos terminar creando otra plataforma .NET que solo admita algunos de estos bloques atómicos pero no todos > ellos. También hubo inquietudes con respecto a cómo nuestras herramientas manejan gráficos de paquetes grandes.En el futuro, simplificaremos esto:
.NET Standard es un bloque de construcción atómico . En otras palabras, las nuevas plataformas no pueden crear subconjuntos de .NET Standard; tienen que implementarlo todo.
Estamos dejando de usar paquetes para describir nuestras plataformas , incluido .NET Standard.
Esto significa que ya no tendrá que hacer referencia a ningún paquete NuGet para .NET Standard. Expresó su dependencia con la carpeta lib, que es exactamente como ha funcionado para todas las demás plataformas .NET, en particular, .NET Framework.
Sin embargo, en este momento nuestras herramientas seguirán quemándose en la referencia a
NETStandard.Library. Tampoco hay daño en eso, simplemente se volverá redundante en el futuro.
Sin embargo, reconozco plenamente que este resultado no es deseable.
Con .NET Standard 1.x y packages.config , lamentablemente no tiene más remedio que producir un .nuspec escrito a mano con grupos de dependencia personalizados. Sin embargo, esto requiere comprender qué paquetes se requieren y tiende a ser frágil. Si el consumidor usa <PackageReference> , es un dolor de cabeza un poco menor porque separa las referencias directas de las transitivas y, por lo tanto, no son tan importantes para usted.
Con .NET Standard 2.0, el problema desaparecerá por completo.
0
Si observa esas referencias de paquetes para net45, encontrará que no hay DLL reales para cargar. El paquete está ahí para que los tiempos de ejecución, como coreclr, que carga todas las partes del BCL como dll, puedan obtenerlos. Sin embargo, en net45, en realidad no encontrará ningún dll en esos paquetes.
En resumen, en .net 4.x, .net seguirá usando la GAC para cargar esos ensamblajes.