Dependencias

La forma principal de agregar dependencias a una biblioteca de .NET hace referencia a paquetes NuGet. Las referencias de paquetes NuGet permiten reutilizar y aprovechar rápidamente la funcionalidad ya escrita, pero son una fuente común de fricción para los desarrolladores de .NET. La administración correcta de dependencias es importante para evitar que los cambios en otras bibliotecas de .NET interrumpan la biblioteca de .NET y viceversa.

Dependencias de diamante

Es habitual que un proyecto de .NET tenga varias versiones de un paquete en su árbol de dependencias. Por ejemplo, una aplicación depende de dos paquetes NuGet, cada uno de los cuales depende de una versión diferente del mismo paquete. Ahora existe una dependencia de diamantes en el gráfico de dependencias de la aplicación.

En tiempo de compilación, NuGet analiza todos los paquetes de los que depende un proyecto, incluidas las dependencias de las dependencias. Cuando se detectan varias versiones de un paquete, las reglas se evalúan para elegir una. La unificación de paquetes es necesaria porque la ejecución de versiones en paralelo de un ensamblado en la misma aplicación es problemática en .NET.

La mayoría de las dependencias de diamantes se resuelven fácilmente; sin embargo, pueden crear problemas en determinadas circunstancias:

• Las referencias de paquetes NuGet en conflicto impiden que se resuelva una versión durante la restauración del paquete.
• Los cambios importantes entre las versiones provocan errores y excepciones en tiempo de ejecución.
• El ensamblaje del paquete está firmemente identificado, la versión del ensamblaje ha cambiado y la aplicación se ejecuta en .NET Framework. Se necesitan redirecciones de enlace de ensamblados.

No es posible saber qué paquetes se usarán junto con los suyos propios. Una buena forma de reducir la probabilidad de que una dependencia de rombo interrumpa la biblioteca es minimizar el número de paquetes de los que usted depende.

✔️ Revise la biblioteca de .NET para ver las dependencias innecesarias.

Intervalos de versiones de dependencia de NuGet

Una referencia de paquete especifica el intervalo de paquetes válidos que permite. Normalmente, la versión de referencia del paquete en el archivo del proyecto es la versión mínima y no hay ningún máximo.

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

Las reglas que NuGet usa al resolver las dependencias son complejas, pero NuGet busca de forma predeterminada la versión aplicable más baja. NuGet prefiere la versión aplicable más baja sobre el uso del más alto disponible, ya que el más bajo tendrá los problemas de compatibilidad mínimos.

Debido a la regla de versión más baja aplicable de NuGet, no es necesario colocar una versión superior o un intervalo exacto en las referencias de paquete para evitar obtener la versión más reciente. NuGet ya intenta encontrar la versión más baja y compatible.

<!-- Accepts 1.0 up to 1.x, but not 2.0 and higher. -->
<PackageReference Include="ExamplePackage" Version="[1.0,2.0)" />

<!-- Accepts exactly 1.0. -->
<PackageReference Include="ExamplePackage" Version="[1.0]" />

Los límites de versión superior harán que NuGet produzca un error si hay un conflicto. Por ejemplo, una biblioteca acepta exactamente 1.0, mientras que otra biblioteca requiere 2.0 o superior. Aunque es posible que se hayan introducido cambios importantes en la versión 2.0, una dependencia de versión de límite estricto o superior garantiza un error.

❌ NO tenga referencias de paquetes NuGet sin versión mínima.

❌ EVITE las referencias de paquetes NuGet que exigen una versión exacta.

❌ EVITE las referencias de paquetes NuGet con un límite superior de versión.

Para obtener más información, consulte Control de versiones de paquetes.

Paquetes de origen compartidos de NuGet

Una manera de reducir las dependencias externas del paquete NuGet es hacer referencia a paquetes de origen compartido. Un paquete de código fuente compartido contiene archivos de código fuente que se incluyen en un proyecto cuando se hace referencia a él. Dado que solo se incluyen archivos de código fuente que se compilan con el resto del proyecto, no hay ninguna dependencia externa ni posibilidad de conflicto.

Los paquetes de origen compartido son excelentes para incluir pequeños fragmentos de funcionalidad. Por ejemplo, puede hacer referencia a un paquete de código fuente compartido de métodos auxiliares para realizar llamadas HTTP.

<PackageReference Include="Microsoft.Extensions.Buffers.Testing.Sources" PrivateAssets="All" Version="1.0" />

Los paquetes de origen compartido tienen algunas limitaciones. Solo se puede hacer referencia a ellos por PackageReference, por lo que se excluyen los proyectos más antiguos packages.config . Además, los proyectos con el mismo lenguaje solo pueden usar los paquetes de código fuente compartidos. Debido a estas limitaciones, los paquetes de código compartido se usan mejor para compartir la funcionalidad dentro de un proyecto de código abierto.

✔️ CONSIDERE la posibilidad de hacer referencia a paquetes de origen compartidos para pequeños elementos internos de funcionalidad.

✔️ CONSIDERE la posibilidad de convertir el paquete en un paquete de origen compartido si proporciona pequeños elementos internos de funcionalidad.

✔️ Haga referencia a paquetes de origen compartidos con PrivateAssets="All".

Esta configuración indica a NuGet que el paquete solo se va a usar en tiempo de desarrollo y no debe exponerse como una dependencia pública.

❌ NO tenga tipos de paquete de origen compartidos en la API pública.

Los tipos de origen compartidos se compilan en el ensamblado de referencia y no se pueden intercambiar a través de los límites del ensamblado. Por ejemplo, un tipo de origen compartido IRepository en un proyecto es un tipo independiente del mismo origen compartido IRepository en otro proyecto. Los tipos de paquetes de código fuente compartido deben tener una visibilidad internal.

❌ NO publique paquetes de origen compartidos en NuGet.org.

Los paquetes de código fuente compartidos contienen código fuente y solo los pueden usar los proyectos con el mismo tipo de lenguaje. Por ejemplo, una aplicación de F# no puede usar un paquete de origen compartido de C#.

Publique paquetes de origen compartidos en una fuente local o MyGet para consumirlos internamente en el proyecto.