Introducción a NuGet

Una herramienta esencial para cualquier plataforma de desarrollo moderna es un mecanismo a través del cual los desarrolladores pueden crear, compartir y consumir código útil. A menudo, este código se agrupa en "paquetes" que contienen código compilado (como DLL) junto con otro contenido necesario en los proyectos que consumen estos paquetes.

Para .NET (incluido .NET Core), el mecanismo compatible con Microsoft para compartir código es NuGet , que define cómo se crean, hospedan y consumen los paquetes de .NET y proporcionan las herramientas para cada uno de esos roles.

En pocas palabras, un paquete NuGet es un único archivo ZIP con la extensión .nupkg que contiene código compilado (DLL), otros archivos relacionados con ese código y un manifiesto descriptivo que incluye información como el número de versión del paquete. Los desarrolladores con código para compartir crean paquetes y los publican en un host público o privado. Los consumidores de paquetes obtienen esos paquetes de hosts adecuados, los agregan a sus proyectos y, a continuación, utilizan la funcionalidad de un paquete en su código del proyecto. A continuación, NuGet controla todos los detalles intermedios.

Dado que NuGet admite hosts privados junto con el host de nuget.org público, puede usar paquetes NuGet para compartir código exclusivo de una organización o un grupo de trabajo. También puede usar paquetes NuGet como una manera cómoda de organizar su propio código para su uso exclusivamente en sus propios proyectos. En resumen, un paquete NuGet es una unidad de código que se puede compartir, pero no requiere ni implica ningún medio concreto de uso compartido.

Flujo de paquetes entre creadores, hosts y consumidores

En su rol como host público, NuGet mantiene el repositorio central de más de 100 000 paquetes únicos en nuget.org. Estos paquetes se emplean por millones de desarrolladores de .NET/.NET Core todos los días. NuGet también permite hospedar paquetes de forma privada en la nube (por ejemplo, en Azure DevOps), en una red privada o incluso en el sistema de archivos local. Al hacerlo, esos paquetes solo están disponibles para aquellos desarrolladores que tienen acceso al host, lo que le da la capacidad de poner paquetes a disposición de un grupo específico de consumidores. Las opciones se explican en Hospedar sus propias fuentes de NuGet. A través de las opciones de configuración, también puede controlar exactamente a qué hosts puede acceder cualquier equipo determinado, lo que garantiza que los paquetes se obtienen de orígenes específicos en lugar de un repositorio público como nuget.org.

Independientemente de su naturaleza, un host actúa como punto de conexión entre los creadores de paquetes y el paquete los consumidores. Los creadores crean paquetes NuGet útiles y los publican en un host. A continuación, los consumidores buscan paquetes útiles y compatibles en hosts accesibles, descargando e incluyendo esos paquetes en sus proyectos. Una vez instalado en un proyecto, las API de los paquetes están disponibles para el resto del código del proyecto.

Compatibilidad con el destino del paquete

Un paquete "compatible" significa que contiene ensamblados creados para al menos un marco de .NET de destino compatible con la plataforma de destino del proyecto de consumo. Los desarrolladores pueden crear paquetes específicos para un marco, como ocurre con los controles UWP, o pueden soportar una gama más amplia de destinos. Para maximizar la compatibilidad de un paquete, los desarrolladores tienen como destino .NET Standard, que todos los proyectos de .NET y .NET Core pueden consumir. Este es el medio más eficaz tanto para los creadores como para los consumidores, ya que un solo paquete (que usualmente contiene un solo componente) funciona para todos los proyectos consumidores.

Los desarrolladores de paquetes que requieren API fuera de .NET Standard, por otro lado, crean ensamblados independientes para las distintas plataformas de destino que desean admitir e incluyen todos esos ensamblados en el mismo paquete (que se denomina "multi-targeting"). Cuando un consumidor instala este paquete, NuGet extrae solo los ensamblados que necesita el proyecto. Esto minimiza la huella del paquete en la aplicación final o en los ensamblados generados por ese proyecto. Un paquete de múltiples objetivos es, por supuesto, más difícil de mantener para su creador.

Nota

Para obtener instrucciones sobre los componentes de la aplicación frente a las bibliotecas reutilizables, consulte la documentación de .NET Standard de sobre el tema.

Herramientas de NuGet

Además de la compatibilidad con el hospedaje, NuGet también proporciona una variedad de herramientas que usan tanto los creadores como los consumidores. Consulte Instalación de herramientas de cliente de NuGet para obtener herramientas específicas.

Herramienta	Plataformas	Escenarios aplicables	Descripción
de la CLI de dotnet	Todo	Creación, consumo	Herramienta de la CLI para bibliotecas de .NET Core y .NET Standard y para proyectos de estilo SDK que tienen como destino .NET Framework (consulte atributo sdk). Proporciona determinadas funcionalidades de la CLI de NuGet directamente dentro de la cadena de herramientas de .NET Core. Al igual que con la CLI de nuget.exe, la CLI de dotnet no interactúa con proyectos de Visual Studio.
nuget.exe CLI	Todos	Creación, consumo	Herramienta de la CLI para bibliotecas de .NET Framework y proyectos que no son de estilo SDK que tienen como destino bibliotecas de .NET Standard. Proporciona todas las funcionalidades de NuGet, con algunos comandos que se aplican específicamente a los creadores de paquetes, algunos solo se aplican a los consumidores y otros se aplican a ambos. Por ejemplo, los creadores de paquetes usan el comando nuget pack para crear un paquete a partir de varios ensamblados y archivos relacionados, los consumidores de paquetes usan nuget install para incluir paquetes en una carpeta del proyecto y todos usan nuget config para establecer variables de configuración de NuGet. Como herramienta independiente de la plataforma, la CLI de NuGet no interactúa con proyectos de Visual Studio.
Consola del Administrador de Paquetes	Visual Studio en Windows	Consumo	Proporciona comandos de PowerShell para instalar y administrar paquetes en proyectos de Visual Studio.
Administrador de paquetes Interfaz de usuario	Visual Studio en Windows	Consumo	Proporciona una interfaz de usuario fácil de usar para instalar y administrar paquetes en proyectos de Visual Studio.
Gestionar la interfaz de usuario de NuGet	Visual Studio para Mac	Consumo	Proporcione una interfaz de usuario fácil de usar para instalar y administrar paquetes en proyectos de Visual Studio para Mac.
de MSBuild	Windows	Creación, consumo	Proporciona la capacidad de crear paquetes y restaurar paquetes usados en un proyecto directamente a través de la cadena de herramientas de MSBuild.

Como puede ver, las herramientas de NuGet con las que trabaja dependen en gran medida de si va a crear, consumir o publicar paquetes y la plataforma en la que está trabajando. Los creadores de paquetes a menudo también son consumidores, ya que se apoyan en la funcionalidad que ofrecen otros paquetes NuGet. Y esos paquetes, por supuesto, pueden depender a su vez de otros.

Para obtener más información, comience con los de flujo de trabajo de creación de paquetes de y flujo de trabajo de consumo de paquetes artículos.

Administración de dependencias

La capacidad de basarse fácilmente en el trabajo de otros es una de las características más eficaces de un sistema de administración de paquetes. En consecuencia, gran parte de lo que NuGet hace es administrar ese árbol de dependencias o "grafo" en nombre de un proyecto. Dicho de manera sencilla, solo necesita preocuparse por esos paquetes que está usando directamente en un proyecto. Si alguno de esos paquetes consume otros paquetes (que, a su vez, puede consumir otros), NuGet se encarga de todas esas dependencias de nivel inferior.

En la imagen siguiente se muestra un proyecto que depende de cinco paquetes, que a su vez dependen de una serie de otros.

Observe que algunos paquetes aparecen varias veces en el gráfico de dependencias. Por ejemplo, hay tres consumidores diferentes del paquete B y cada consumidor también puede especificar una versión diferente para ese paquete (no se muestra). Se trata de una aparición común, especialmente para paquetes ampliamente usados. NuGet realiza afortunadamente todo el trabajo duro para determinar exactamente qué versión del paquete B satisface a todos los consumidores. Después, NuGet hace lo mismo para todos los demás paquetes, independientemente de la profundidad del gráfico de dependencias.

Para obtener más información sobre cómo realiza NuGet este servicio, consulte Resolución de dependencias.

Seguimiento de referencias y restauración de paquetes

Dado que los proyectos pueden moverse fácilmente entre equipos de desarrollador, repositorios de control de código fuente, servidores de compilación, etc., es muy poco práctico mantener los ensamblados binarios de paquetes NuGet enlazados directamente a un proyecto. Si lo hace, cada copia del proyecto se sobredimensiona innecesariamente (y, por tanto, desperdicia espacio en repositorios de control de código fuente). También sería muy difícil actualizar los archivos binarios del paquete a versiones más recientes, ya que las actualizaciones tendrían que aplicarse en todas las copias del proyecto.

NuGet mantiene en su lugar una lista de referencia simple de los paquetes en los que depende un proyecto, incluidas las dependencias de nivel superior y inferior. Es decir, siempre que instale un paquete de algún host en un proyecto, NuGet registra el identificador del paquete y el número de versión en la lista de referencia. (Desinstalar un paquete, por supuesto, lo quita de la lista). A continuación, NuGet proporciona un medio para restaurar todos los paquetes a los que se hace referencia a petición, como se describe en Restauración de paquetes.

Con solo la lista de referencias, NuGet puede volver a instalar, es decir, restaurar, todos esos paquetes de hosts públicos o privados en cualquier momento posterior. Al confirmar un proyecto en el control de código fuente o compartirlo de alguna otra manera, solo se incluye la lista de referencia y se excluyen los archivos binarios de paquete (consulte Paquetes y control de código fuente).

El equipo que recibe un proyecto, como un servidor de compilación que obtiene una copia del proyecto como parte de un sistema de implementación automatizado, simplemente pide a NuGet que restaure las dependencias siempre que sea necesario. Los sistemas de compilación como Azure DevOps proporcionan pasos de "restauración de NuGet" para este propósito exacto. De forma similar, cuando los desarrolladores obtienen una copia de un proyecto (como al clonar un repositorio), pueden invocar comandos como nuget restore (CLI de NuGet), dotnet restore (CLI de dotnet) o Install-Package (consola del Administrador de paquetes) para obtener todos los paquetes necesarios. Visual Studio, por su parte, restaura automáticamente los paquetes al compilar un proyecto (siempre que la restauración automática esté habilitada, como se describe en Restauración de paquetes).

A continuación, el rol principal de NuGet en el que los desarrolladores están interesados es mantener esa lista de referencias en nombre del proyecto y proporcionar los medios para restaurar de forma eficaz (y actualizar) los paquetes a los que se hace referencia. Esta lista se mantiene en uno de los dos formatos de administración de paquetes , tal como se les llama.

• PackageReference (o "referencias de paquete en archivos de proyecto") | (NuGet 4.0+) Mantiene una lista de las dependencias de nivel superior de un proyecto directamente dentro del archivo del proyecto, por lo que no se necesita ningún archivo independiente. Un archivo asociado, obj/project.assets.json, se genera dinámicamente para administrar el gráfico de dependencias general de los paquetes que un proyecto usa junto con todas las dependencias de nivel inferior. Los proyectos de .NET Core siempre usan PackageReference.

• packages.config: (NuGet 1.0+) Un archivo XML que mantiene una lista plana de todas las dependencias del proyecto, incluidas las dependencias de otros paquetes instalados. Los paquetes instalados o restaurados se almacenan en una carpeta packages.

El formato de administración de paquetes que se emplea en cualquier proyecto determinado depende del tipo de proyecto y de la versión disponible de NuGet (o Visual Studio). Para comprobar qué formato se usa, simplemente busque packages.config en la raíz del proyecto después de instalar el primer paquete. Si no tiene ese archivo, busque un elemento <PackageReference> directamente en el archivo de proyecto.

Cuando tenga una opción, se recomienda usar PackageReference. packages.config se mantiene por motivos de compatibilidad con el pasado y ya no está en desarrollo activo.

Propina

Varios comandos de nuget.exe CLI, como nuget install, no agregan automáticamente el paquete a la lista de referencias. La lista se actualiza al instalar un paquete con el Administrador de paquetes de Visual Studio (INTERFAZ de usuario o consola) y con dotnet.exe CLI.

¿Qué más hace NuGet?

Hasta ahora ha aprendido las siguientes características de NuGet:

• NuGet proporciona el repositorio central nuget.org con compatibilidad con el hospedaje privado.
• NuGet proporciona las herramientas que los desarrolladores necesitan para crear, publicar y consumir paquetes.
• Lo más importante es que NuGet mantiene una lista de referencia de paquetes usados en un proyecto y la capacidad de restaurar y actualizar esos paquetes de esa lista.

Para que estos procesos funcionen de forma eficaz, NuGet realiza algunas optimizaciones en segundo plano. Más notablemente, NuGet administra una caché de paquetes y una carpeta global de paquetes para agilizar la instalación y reinstalación. La memoria caché evita descargar un paquete que ya se ha instalado en la máquina. La carpeta de paquetes globales permite que varios proyectos compartan el mismo paquete instalado, lo que reduce la superficie general de NuGet en el equipo. La carpeta caché y paquetes globales también son muy útiles cuando se restaura con frecuencia un mayor número de paquetes, como en un servidor de compilación. Para obtener más información sobre estos mecanismos, consulte Administración de los paquetes globales y las carpetas de caché.

Dentro de un proyecto individual, NuGet administra el gráfico de dependencias general, que de nuevo incluye la resolución de varias referencias a versiones diferentes del mismo paquete. Es bastante común que un proyecto tome una dependencia de uno o varios paquetes que tienen las mismas dependencias. Algunos de los paquetes de utilidad más útiles en nuget.org son empleados por muchos otros paquetes. En todo el gráfico de dependencias, puede tener fácilmente diez referencias diferentes a distintas versiones del mismo paquete. Para evitar llevar varias versiones de ese paquete a la propia aplicación, NuGet ordena qué versión única pueden usar todos los consumidores. (Para obtener más información, consulte Resolución de dependencias.)

Además, NuGet mantiene todas las especificaciones relacionadas con cómo se estructuran los paquetes (incluyendo localización y símbolos de depuración ) y a cómo se les hace referencia (incluyendo los intervalos de versiones y versiones preliminares ). NuGet también proporciona varias API para trabajar con sus servicios mediante programación y ofrece soporte para desarrolladores que escriben extensiones y plantillas de proyecto de Visual Studio.

Dedique un momento a examinar la tabla de contenido de esta documentación y verá todas estas funcionalidades representadas allí, junto con las notas de la versión que datan de los comienzos de NuGet.

Vídeo relacionado

Encuentra vídeos de NuGet en Channel 9 y YouTube.

Comentarios, contribuciones y problemas

Por último, agradecemos enormemente los comentarios y las contribuciones a esta documentación; simplemente seleccione los comandos de Comentarios y Editar en la parte superior de cualquier página, o visite el repositorio de documentación y la lista de problemas de documentación en GitHub.

También agradecemos las contribuciones a NuGet a través de sus varios repositorios de GitHub; Los problemas de NuGet se pueden encontrar en https://github.com/NuGet/home/issues.

¡Disfruta de tu experiencia nuGet!