Administración de actualizaciones de dependencias en el proyecto de .NET

Completado

Antes o más tarde, quiere actualizar a una nueva versión de una biblioteca. Tal vez una función se haya marcado como en desuso o puede que haya una nueva característica en una versión posterior de un paquete que está usando.

Tenga en cuenta estas consideraciones antes de intentar actualizar una biblioteca:

• El tipo de actualización: ¿qué tipo de actualización está disponible? ¿Se trata de una pequeña corrección de errores? ¿Agrega una característica nueva que necesita? ¿Interrumpe el código? Puede comunicar el tipo de actualización mediante un sistema denominado versionamiento semántico. La manera en que se expresa el número de versión de la biblioteca indica al desarrollador el tipo de actualización con el que trata.
• Si el proyecto está configurado correctamente: el proyecto de .NET se puede configurar de forma que solo obtenga los tipos de actualizaciones que le interesen. Solo se realiza una actualización si hay disponible un tipo específico de actualización. Este es el enfoque recomendado para evitar sorpresas.
• Problemas de seguridad: la administración de las dependencias del proyecto a lo largo del tiempo conlleva tener en cuenta los problemas que puedan producirse. Por ejemplo, pueden surgir problemas cuando se detectan vulnerabilidades. Idealmente, se liberan las revisiones que puede descargar. La herramienta de .NET Core ayuda a ejecutar una auditoría en las bibliotecas para averiguar si tiene paquetes que se deban actualizar. También le ayuda a realizar las acciones adecuadas para solucionar un problema.

Uso del versionamiento semántico

Existe un estándar en la industria llamado versionamiento semántico, que es la forma de expresar el tipo de cambio que usted u otro desarrollador introducen en una biblioteca. El versionamiento semántico garantiza que un paquete tenga un número de versión dividido en estas secciones:

• Versión principal: número situado más a la izquierda. Por ejemplo, es el 1 de 1.0.0. Un cambio en este número significa que puede esperar "cambios importantes" en el código. Es posible que tenga que volver a escribir parte del código.
• Versión secundaria: número del medio. Por ejemplo, es el 2 de 1.2.0. Un cambio en este número significa que se agregaron características. El código debería seguir funcionando. Normalmente es seguro aceptar la actualización.
• Versión de revisión: número más a la derecha. Por ejemplo, es el 3 de 1.2.3. Un cambio en este número significa que se aplicó un cambio que corrige algo en el código que debería funcionar. Debería ser seguro aceptar la actualización.

En esta tabla se muestra cómo cambia el número de versión de cada tipo de versión:

Tipo	¿Qué sucede?
Versión principal	1.0.0 cambios en 2.0.0
Versión secundaria	1.1.1 cambios en 1.2.0
Versión de revisión	1.0.1 cambios en 1.0.2

Muchas empresas y desarrolladores usan este sistema. Si piensa publicar paquetes e insertarlos en el registro NuGet, se espera que siga el control de versiones semántico. Incluso si solo descarga paquetes del registro de NuGet, lo más probable es que sigan el versionamiento semántico.

Los cambios en un paquete pueden presentar riesgos, como el hecho de que un error pueda perjudicar su negocio. Algunos riesgos podrían requerir que vuelva a escribir parte del código. La reescritura de código lleva tiempo y cuesta dinero.

Enfoque de actualización

Como desarrollador de .NET, puede comunicar a .NET el comportamiento de actualización de su preferencia. Piense en la actualización en términos del riesgo. Estos son algunos enfoques:

• Versión principal: estoy de acuerdo con la actualización a la versión principal más reciente en cuanto se publique. Acepto el hecho de que es posible que tenga que cambiar el código.
• Versión secundaria: me parece bien que se incorpore una característica nueva. No me gusta que el código se interrumpa.
• Versión de revisión: las únicas actualizaciones que me interesan son las correcciones de errores.

Si va a administrar un proyecto de .NET nuevo o más pequeño, puede permitirse cierta flexibilidad en el modo de definir la estrategia de actualización. Por ejemplo, siempre puede actualizar a la última versión. En el caso de proyectos más complejos, existen más matices, pero se describirán en un módulo futuro.

En general, cuanto menor sea la dependencia que va a actualizar, menos dependencias tiene y más probable es que el proceso de actualización sea fácil.

Configuración del archivo de proyecto para la actualización

Al agregar una o varias dependencias, configure el archivo del proyecto para obtener un comportamiento predecible al restaurar, compilar o ejecutar el proyecto. Puede comunicar el enfoque que quiere adoptar para un paquete. NuGet tiene los conceptos de los intervalos de versiones y versiones flotantes.

Los intervalos de versiones son una notación especial que puede usar para indicar un intervalo específico de versiones que desea resolver.

Notación	Regla aplicada	Descripción
1.0	x >= 1.0	Versión mínima, incluida
(1.0,)	x > 1.0	Versión mínima, excluida
[1.0]	x == 1.0	Coincidencia de versión exacta
(,1.0]	x ≤ 1.0	Versión máxima, incluida
(,1.0)	x < 1.0	Versión máxima, excluida
[1.0,2.0]	1.0 ≤ x ≤ 2.0	Intervalo exacto, ambos incluidos
(1.0,2.0)	1.0 < x < 2.0	Intervalo exacto, ambos excluidos
[1.0,2.0)	1.0 ≤ x < 2.0	Versión mínima incluida y versión máxima excluida mezcladas
(1.0)	no válido	no válido

NuGet también admite el uso de una notación de versión flotante para partes de sufijo principal, secundaria, revisión y versión preliminar del número. Esta notación es un asterisco (*). Por ejemplo, la especificación de la versión 6.0.* indica "use la versión 6.0.x más reciente". En otro ejemplo, 4.* significa "use la versión 4.x más reciente". El uso de una versión flotante reduce los cambios en el archivo del proyecto, a la vez que se mantiene al día con la última versión de una dependencia.

Nota:

Se recomienda instalar una versión específica, en lugar de usar cualquiera de las notaciones flotantes. Instalar una versión específica garantiza que las compilaciones se puedan repetir, a menos que se solicite explícitamente una actualización de una dependencia.

Cuando se usa una versión flotante, NuGet resuelve la última versión de un paquete que coincide con el patrón de versión. En el ejemplo siguiente, 6.0.* obtiene la última versión de un paquete que empieza por 6.0. Esa versión es 6.0.1.

Estos son algunos ejemplos que se pueden configurar para la versión principal, secundaria o de revisión:

<!-- Accepts any version 6.1 and later. -->
<PackageReference Include="ExamplePackage" Version="6.1" />

<!-- Accepts any 6.x.y version. -->
<PackageReference Include="ExamplePackage" Version="6.*" />
<PackageReference Include="ExamplePackage" Version="[6,7)" />

<!-- Accepts any later version, but not including 4.1.3. Could be
     used to guarantee a dependency with a specific bug fix. -->
<PackageReference Include="ExamplePackage" Version="(4.1.3,)" />

<!-- Accepts any version earlier than 5.x, which might be used to prevent pulling in a later
     version of a dependency that changed its interface. However, we don't recommend this form because determining the earliest version can be difficult. -->
<PackageReference Include="ExamplePackage" Version="(,5.0)" />

<!-- Accepts any 1.x or 2.x version, but not 0.x or 3.x and later. -->
<PackageReference Include="ExamplePackage" Version="[1,3)" />

<!-- Accepts 1.3.2 up to 1.4.x, but not 1.5 and later. -->
<PackageReference Include="ExamplePackage" Version="[1.3.2,1.5)" />

Búsqueda y actualización de paquetes obsoletos

El comando dotnet list package --outdated muestra los paquetes obsoletos. Este comando puede ayudarle a aprender cuándo hay disponibles versiones más recientes de los paquetes. Esta es una salida típica del comando:

Top-level Package      Requested   Resolved   Latest
> Humanizer            2.7.*       2.7.9      2.8.26

Estos son los significados de los nombres de las columnas en la salida:

• Requested: Versión o intervalo de versiones que especificó.
• Resolved: Versión real descargada para el proyecto que coincide con la versión especificada.
• Latest: versión más reciente disponible para la actualización desde NuGet.

El flujo de trabajo recomendado es ejecutar los siguientes comandos, en este orden:

1. Ejecute dotnet list package --outdated. Este comando enumera todos los paquetes obsoletos. Proporciona información en las columnas Requested, Resolved y Latest.
2. Ejecute dotnet add package <package name>. Si ejecuta este comando, intenta actualizar a la versión más reciente. Opcionalmente, puede pasar --version=<version number/range>.