.NET: paquetes NuGet offline

Típicamente, un proyecto .NET consume bibliotecas estándar y de terceros a través de nuget.org. Contextualizando un poco, NuGet es el gestor de paquetes o (package manager) de facto del ecosistema .NET, como npm para Javascript, PyPI para Python, Maven para Java, Conan para C++, etcétera. Es una práctica bastante establecida que las organizaciones tengan un repositorio NuGet privado alojado en un servicio de hosting de binarios como Artifactory o Nexus. Si la organización desarrolla sus propias bibliotecas, las alojará en dicho repositorio. Así, podrán ser reusadas entre distintos equipos de desarrollo dentro de la organización, e incluso fuera de la misma si se opta por hacerlas públicas.

Todo esto está muy bien, pero a veces el servicio de alojamiento de binarios se cae, o se desea modificar las bibliotecas localmente antes de desplegarlas. En escenarios así, resulta útil tener una fuente NuGet adicional alojada en la máquina del desarrollador. Dicha fuente puede ser utilizada al desarrollar aplicaciones .NET; es aquí donde aparece el concepto de paquetes offline.

La interacción con fuentes de NuGet puede efectuarse de manera independiente del sistema operativo e IDE, utilizando dotnet cli, la interfaz de línea de comando del SDK de .NET. Para comenzar, las fuentes de NuGet actualmente configuradas en el sistema pueden ser listadas ejecutando el siguiente comando en una terminal:

dotnet nuget list source

Este comando imprimirá una lista de las fuente NuGet configuradas para el sistema, especificando para cada una si está habilitada o no. Un ejemplo de dicha salida sería:

Registered Sources:
  1.  nuget.org [Enabled]
      https://api.nuget.org/v3/index.json
  2.  Artifactory [Disabled]
      https://artifactory.organization.domain/artifactory/api/nuget/organization-nuget
  3.  Microsoft Visual Studio Offline Packages [Enabled]
      C:\Program Files (x86)\Microsoft SDKs\NuGetPackages\
  4.  Artifactory-dev [Disabled]
      https://artifactory.organization.domain/artifactory/api/nuget/v3/organization-nuget-dev

En este ejemplo se tiene nuget.org como la fuente 1, dos fuentes de Artifactory de la organización como fuentes 2 y 4, y una fuente offline como fuente 3. Esta última es creada automáticamente por Visual Studio. Nótese que está vinculada a un directorio local, C:\Program Files (x86)..., en lugar de a una URL como las otras. Esto es una característica distintiva de una fuente local.

Si una fuente offline no existe, puede crearse manualmente.

dotnet nuget add source <path-a-directorio-local-dir> --name <nombre-de-fuente>

Si la fuente ya existe pero está deshabilitada, puede ser habilitada.

dotnet nuget enable source <nombre-de-fuente>

Una vez que la fuente local existe y está habilitada, todo lo que resta es publicar paquetes en ella. Esto puede llegar a requerir privilegios administrativos dependiendo del directorio asociado. En el ejemplo anterior, dado que el directorio está dentro de C:\Program Files (x86), escribir allí requerirá privilegios administrativos para un usuario limitado de Windows. Lo mismo puede ocurrir en Linux si el directorio de la fuente está dentro de un directorio cuyo dueño sea el usuario root. En esos casos, en Windows, el comando para publicar paquetes deberá ser ejecutado dentro de una terminal con derechos de administrador. En Linux, sudo podrá ser necesario. Hecha esta consideración, el comando para publicar paquetes es el siguiente:

dotnet nuget push <path-a-binario-de-biblioteca>.nupkg -s <nombre-de-fuente>

Es importante recordar que los binarios a publicar deben estar en formato .nupkg. Estos binarios suelen incluir el número de versión en su nombre, pero si no es el caso, eso es parte de sus metadatos. Es clave recordar que el par formado por el nombre de la biblioteca y su número de versión son el identificador unívoco para que NuGet determine la versión exacta a utilizar. Además, se recomienda utilizar versionado semántico para todos los números de versión.

¡Eso es todo por hoy! ¡Felices fiestas!