Incorporación de paquetes al proyecto de .NET

  • 2 minutos

.NET incluye muchas bibliotecas principales que lo controlan todo, desde la administración de archivos y HTTP hasta la compresión de archivos. Existe un ecosistema enorme de bibliotecas de terceros. Puede usar NuGet, el administrador de paquetes de .NET, para instalar estas bibliotecas y usarlas en la aplicación.

En .NET y en su ecosistema se usa mucho la palabra dependencia. Una dependencia de paquete es una biblioteca de terceros. Se trata de un fragmento de código reutilizable que lleva a cabo una tarea y que puede añadir a su aplicación. La biblioteca de terceros es algo de lo que la aplicación depende para funcionar, de ahí la palabra dependencia.

Puede considerar la biblioteca de terceros como un paquete almacenado en un repositorio. Un paquete consta de una o varias bibliotecas que se pueden agregar a la aplicación para aprovechar sus características.

Aquí, nos centraremos en las dependencias de paquetes. Sin embargo, un proyecto de .NET puede tener otros tipos de dependencias además de las dependencias del paquete. Incluidas, marcos, analizadores, referencias de proyecto y dependencias de proyecto compartidas.

Determinación de la necesidad de un paquete

¿Cómo puede saber si necesita un paquete para el proyecto? Esta es una pregunta complicada que implica varios factores:

  • Obtención de código mejor: Pregúntese si se trata de un área como la seguridad, por ejemplo, y si intenta implementar la autenticación y la autorización. Es muy importante tenerlo claro para proteger los datos personales y los de los clientes. Muchos desarrolladores usan los patrones estándar y las bibliotecas que están disponibles. Estas bibliotecas implementan características que probablemente siempre necesita y los problemas se corrigen a medida que se producen. Debería usar estas bibliotecas en lugar de crear una propia. Probablemente no escriba el código tan bien personalmente, ya que hay muchos casos extremos que debe tener en cuenta.
  • Ahorro de tiempo: Probablemente pueda compilar por su cuenta la mayoría de los elementos, como bibliotecas de utilidades o de componentes de interfaz de usuario, pero esto lleva tiempo. Aunque los resultados son comparables a lo que ya está disponible, no vale la pena perder tiempo en replicar el trabajo.
  • Mantenimiento: tarde o temprano, debe realizarse un mantenimiento de todas las bibliotecas y aplicaciones. El mantenimiento implica agregar nuevas características y corregir errores. ¿Vale la pena invertir su tiempo o el de su equipo en el mantenimiento de una biblioteca? ¿O es mejor dejarlo en manos de un equipo de software de código abierto?

Evaluación de un paquete

Antes de instalar una biblioteca, es posible que le interese inspeccionar las dependencias en las que se basa. Estas dependencias pueden animarle a usar el paquete, o bien podrían disuadirle. Estos son algunos factores que tener en cuenta al seleccionar una dependencia para el proyecto:

  • Tamaño: El número de dependencias puede crear una superficie de memoria grande. Si dispone de ancho de banda limitado o tiene otras limitaciones de hardware, este factor puede suponer un problema.
  • Licencias: Debe asegurarse de que la licencia concedida para la biblioteca cubre el uso previsto, tanto si se trata de un uso comercial, personal o académico.
  • Mantenimiento activo: Puede ser un problema si el paquete depende de una dependencia que no se mantiene activamente. La dependencia podría estar en desuso o no actualizarse durante mucho tiempo.

Para obtener más información sobre un paquete antes de instalarlo, vaya a https://www.nuget.org/packages/<package name>. Esta dirección URL le lleva a una página con los detalles del paquete. Seleccione la lista desplegable Dependencias para ver de qué paquetes depende para funcionar.

Puede que el número de dependencias mostradas no sea del todo ilustrativo. Si descarga un paquete, podría acabar con una dependencia de paquete que contiene docenas de paquetes. ¿A qué se debe? Cada paquete tiene una lista de dependencias. Para asegurarse de poder usar un paquete, todas las dependencias se rastrean y se descargan cuando se ejecuta el comando dotnet add package <package name>.

Instalación de un paquete

Hay varias maneras de instalar paquetes. Visual Studio y Visual Studio para Mac tienen integrada una interfaz de usuario gráfica y una línea de comandos para un administrador de paquetes. Puede agregar manualmente referencias de paquetes al archivo de proyecto o puede instalarlas a través de una herramienta de interfaz de línea de comandos (CLI), como Paket o la CLI de .NET Core.

En este módulo, vamos a usar la CLI de .NET Core integrada para instalar paquetes. Puede agregar un paquete al proyecto de .NET mediante la invocación de un comando en el terminal. Un comando de instalación típico es similar a este: dotnet add package <name of package>. Al ejecutar el comando add package, la herramienta de línea de comandos se conecta a un registro global, captura el código y lo almacena en una ubicación de carpeta en la memoria caché que puedan usar todos los proyectos.

Después de que el proyecto se instale y se compile, se agregan las referencias a las carpetas Debug o Release. El directorio del proyecto tendrá un aspecto similar a este:

-| bin/
---| Debug/
------| net3.1
--------| <files included in the dependency>

Búsqueda de un paquete

Es posible que desarrolladores individuales usen el registro global de NuGet.org para buscar y descargar los paquetes que necesitan para sus aplicaciones. Es posible que una empresa aplique una estrategia para saber qué paquetes se pueden usar y dónde buscarlos.

Captura de pantalla de NuGet.org en la que se muestra una lista de paquetes populares.

Los paquetes se podrían encontrar en muchos lugares diferentes. Algunos de estos orígenes podrían estar disponibles públicamente, mientras que otros tal vez estén restringidos y solo estén disponibles para los empleados de una empresa específica. Estos son algunos lugares donde podrían estar los paquetes:

  • Registros: Un ejemplo podría ser un registro global, como el de NuGet.org. Puede hospedar registros propios, ya sean privados o públicos. Hay registros privados disponibles a través de servicios como GitHub y Azure DevOps.
  • Archivos: Puede instalar un paquete desde una carpeta local. La instalación desde un paquete es habitual cuando se intentan desarrollar bibliotecas propias de .NET y se quiere probar el paquete de forma local. O bien cuando no se quiere usar un registro por el motivo que sea.

Diagrama en el que se ilustra la relación entre los creadores, los hosts y los consumidores de paquetes.

Registro de NuGet y herramienta dotnet

Al ejecutar dotnet add package <name of dependency>, .NET va a un registro global, denominado registro de NuGet.org ubicado en https://nuget.org, y busca el código que se va a descargar. También puede buscar paquetes en esta página si accede a ella con un explorador. Cada paquete tiene un sitio web dedicado que puede visitar.

Captura de pantalla de la página de aterrizaje de un paquete NuGet.

En estos sitios, puede obtener más información sobre dónde reside el código fuente. También puede encontrar información como las métricas de las descargas e información sobre el mantenimiento.

Captura de pantalla con información y métricas de un paquete NuGet.

Comandos .NET

Hasta ahora, ha obtenido información sobre cómo puede instalar dependencias con la CLI de .NET Core. Pero esta herramienta puede hacer mucho más.

La CLI de .NET Core tiene bastantes comandos. Los comandos le ayudan con tareas como la instalación o la creación de paquetes, y la inicialización de proyectos de .NET. No es necesario conocer todos los comandos en detalle. Cuando empiece a usar .NET, es probable que emplee solo un subconjunto de los comandos. A medida que expande el uso de .NET, puede usar más comandos de varias categorías.

Para ayudarle a recordar qué hacen los comandos, puede considerarlos como pertenecientes a categorías:

  • Administración de dependencias: Los comandos de esta categoría cubren la instalación, eliminación, limpieza después de las instalaciones de paquetes y la actualización de paquetes.
  • Ejecución de programas: La herramienta de .NET Core puede ayudarle a administrar flujos en el desarrollo de la aplicación. Como ejemplos de flujos de aplicación podrían citarse la ejecución de pruebas, la compilación de código y la ejecución de comandos de migración para actualizar proyectos.
  • Creación y publicación de paquetes: Hay varios comandos que pueden ayudarle con tareas como la creación de un paquete comprimido y su inserción en un registro.

Si quiere obtener una lista detallada de todos los comandos, escriba dotnet --help en el terminal.

Procedimiento para instalar un paquete

Use el comando dotnet add package <dependency name> para instalar una dependencia normal que está diseñada para usarse como parte de la aplicación.

Nota:

Puede instalar algunos paquetes globalmente. Estos paquetes no están pensados para importarse en el proyecto. Por este motivo, muchos paquetes globales son herramientas de la CLI o plantillas. También puede instalar estas herramientas globales desde un repositorio de paquetes. Instale las herramientas con el comando dotnet tool install <name of package>. Instale las plantillas con el comando dotnet new -i <name of package>.

Después de la instalación

Los paquetes instalados se indican en la sección dependencies del archivo .csproj. Si quiere ver qué paquetes hay en la carpeta, puede escribir dotnet list package.

Project 'DotNetDependencies' has the following package references
   [net8.0]:
   Top-level Package      Requested   Resolved
   > Humanizer            2.7.9       2.7.9

Este comando solo muestra los paquetes de nivel superior, no las dependencias de dichos paquetes que denominamos transitivos. Este comando es muy útil para una vista rápida. Si desea una vista más detallada, puede enumerar todos los paquetes transitivos. Al hacerlo, el comando list tiene el aspecto siguiente:

dotnet list package --include-transitive

La inclusión de los transitivos le permite ver las dependencias junto con todos los paquetes que haya instalado. Si ejecuta dotnet list package --include-transitive, es posible que obtenga este resultado:

Project 'DotNetDependencies' has the following package references
   [net8.0]:
   Top-level Package      Requested   Resolved
   > Humanizer            2.7.9       2.7.9

   Transitive Package               Resolved
   > Humanizer.Core                 2.7.9
   > Humanizer.Core.af              2.7.9
   > Humanizer.Core.ar              2.7.9
   > Humanizer.Core.bg              2.7.9
   > Humanizer.Core.bn-BD           2.7.9
   > Humanizer.Core.cs              2.7.9
   ...

Restauración de dependencias

Al crear o clonar un proyecto, las dependencias incluidas no se descargan ni se instalan hasta que se compila el proyecto. Mediante la ejecución del comando dotnet restore, puede restaurar manualmente las dependencias y las herramientas específicas del proyecto que se especifican en el archivo de proyecto. En la mayoría de los casos, no es necesario usar explícitamente el comando. La restauración de NuGet se ejecuta implícitamente, si es necesario, cuando se ejecutan comandos como new, build y run.

Limpieza de las dependencias

Tarde o temprano es probable que se dé cuenta de que ya no necesita un paquete. O bien, es posible que el paquete que ha instalado no sea el que necesita. Puede que haya encontrado uno que realice mejor una tarea. Sea cual sea el motivo, debe quitar las dependencias que no use. Al hacerlo, todo se mantiene limpio. Además, las dependencias ocupan espacio.

Para quitar un paquete del proyecto, use el comando remove de la siguiente manera: dotnet remove package <name of dependency>. Este comando quita el paquete del archivo .csproj del proyecto.