Tenemos un marco que se divide en muchos proyectos separados en una solución. Ahora quiero crear paquetes NuGet para cada proyecto por separado, pero garantizo que solo se puede usar una versión del marco en una solución (posiblemente en varios proyectos).
Por ejemplo, supongamos que el marco se compone de dos proyectos:
Framework Framework_1 Framework_2 Ahora, al usar este marco, un proyecto puede hacer referencia a Framework_1 , mientras que otro proyecto hace referencia a Framework_2 . Quiero asegurarme de que ambos paquetes tengan la misma versión (puntos de bonificación si hay un proceso sencillo de un solo paso para actualizar a una versión más nueva)
Pensé que simplemente definiría un paquete Framework de nivel de solución del que todos los demás paquetes dependen estrictamente. El problema es que NuGet no tiene problemas simplemente instalando varias versiones del paquete de nivel de solución.
Básicamente probé lo siguiente:
Archivo nuspec de nivel de solución:
<?xml version="1.0"?> <package xmlns="http://schemas.microsoft.com/packaging/2011/08/nuspec.xsd"> <metadata> <id>My.Framework</id> <version>1.0.0</version> <title>My.Framework</title> <authors>voo</authors> <owners>voo</owners> <requireLicenseAcceptance>false</requireLicenseAcceptance> <description>Some Framework Solution Package</description> <copyright>Copyright © 2015</copyright> </metadata> </package>Y un paquete nuspec para una parte:
<?xml version="1.0"?> <package xmlns="http://schemas.microsoft.com/packaging/2011/08/nuspec.xsd"> <metadata> <id>My.Framework.BL</id> <version>1.0.0</version> <title>My.Framework.BL</title> <authors>voo</authors> <owners>voo</owners> <requireLicenseAcceptance>false</requireLicenseAcceptance> <description>Business Layer</description> <copyright>Copyright © 2015</copyright> <dependencies> <dependency id="My.Framework" version="[1.0.0]"/> </dependencies> </metadata> </package> El problema ahora es que si intentara instalar, digamos otro paquete My.Framework.EF con la versión 1.0.1 y una dependencia explícita de My.Framework 1.0.1, Visual Studio simplemente instalaría My.Framework dos veces, una vez con la versión 1.0.0 y una vez con 1.0.1.
puede restringir la versión de su paquete usando la siguiente sintaxis en su packages.config como:
<package id="jQuery" version="1.9.1" allowedVersions="[1.9.1]" />También de la documentación nuget original: cuando crea un paquete NuGet, puede especificar dependencias para el paquete en el archivo .nuspec.
<dependency id="ExamplePackage" version="[1,3)" />En el ejemplo, la versión 1 y la versión 2.9 serían aceptables, pero no la 0.9 ni la 3.0.
Supongo que puede limitarlo de esta manera a un rango único o determinado de versiones. Aquí puedes leer más al respecto.
Puede crear una prueba de unidad simple dentro de su solución para advertirle cuando tenga un problema. El código está debajo.
Deberá install-package NuGet.Core dentro de su proyecto de prueba unitaria para que funcione el siguiente código.
using System; using System.Diagnostics; using System.IO; using System.Linq; using Microsoft.VisualStudio.TestTools.UnitTesting; using NuGet; [TestClass] public class NugetPackagesTest { /// <summary> /// This test method makes sure that we do not install different versions of the same nuget package /// across the solution. For example this test will fail if one project references EntityFramework /// version 6.1.3 and another project references version 6.2.0. Having different versions of the same /// package installed often results in unexpected and hard-to-understand errors. /// </summary> [TestMethod] public void PackagesAccrossProjectsAreOfSameVersion() { var dir = GetSolutionRoot(); Debug.Assert(dir != null, nameof(dir) + " != null"); var filePaths = Directory.GetFiles(dir.FullName, "*packages.config", SearchOption.AllDirectories); var installedPackages = filePaths .Select(t => new PackageReferenceFile(t)) .SelectMany(t => t.GetPackageReferences().Select(x => new { File = t, Package = x })) .GroupBy(t => t.Package.Id) .ToList(); foreach (var package in installedPackages) { var versions = package .Select(t => t.Package.Version.ToNormalizedString()) .Distinct() .ToList(); var report = package .Select(t => $"{t.Package.Version} @ {t.File.FullPath}") .OrderBy(t => t); Assert.IsTrue( versions.Count == 1, $"Multiple versions of package {package.Key} are installed: {string.Join(", ", versions)}.\n" + $"{string.Join("\n", report)}"); } } private static DirectoryInfo GetSolutionRoot() { var current = AppDomain.CurrentDomain.BaseDirectory; var dir = Directory.GetParent(current); while (dir != null) { // TODO: replace with name your solution's folder. if (dir.Name == "MySolution") { dir = dir.Parent; break; } dir = dir.Parent; } return dir; } }Quitaría el "Paquete NuGet de nivel de solución", dividiría su marco en componentes y crearía un paquete NuGet por componente. Nadie va a tener 1 solo proyecto que haga referencia a su paquete NuGet "Framework Wrapper" y código para Business Logic, Data Access y WCF dentro de ese único proyecto.
Luego, lo que debe hacer es aclarar cuál es realmente su lógica de dependencia y cuál es el razonamiento detrás de querer hacer cumplir estrictamente una política de la misma versión .
Por ejemplo, supongamos que My.Framework.BL depende de My.Framework.DAL. Entonces, en este punto, solo tiene 2 archivos Nuspec y 2 paquetes NuGet, con el .nuspec de su My.Framework.BL con este aspecto:
<dependencies> <dependency id="My.Framework.DAL" version="1.0.0" /> </dependencies>Y con su My.Framework.DAL que no contiene dependencias específicas de My.Framework.
Esto está bien, y su solución de querer acoplar estrechamente el número asociado con la versión es problemática por varias razones. El primero y más importante es que confundirá a los consumidores de su marco si actualizó My.Framework.DAL cuando tiene 0 cambios, pero tuvo que actualizarlo porque cambió My.Framework.BL.
Podría pasar un mes, o posiblemente más, y no tener que actualizar una dependencia de My.Framework, según el nivel de abstracción de su marco y el grado de programación de bajo nivel que esté realizando. En mi opinión, tener que actualizar las versiones dll de Core Framework cuando en realidad no hay cambios nuevos es un problema MUCHO más grande que los números de versión de todos los dlls de My.Framework que son iguales. Salud. :)
Aquí están los documentos de referencia de nuspec.