Todo lo que necesitas saber para publicar NuGets

Source: Dev.to

En el artículo anterior analizamos cómo sobrevivir al infierno de las dependencias desde la perspectiva del consumidor. Sin embargo, el verdadero salto de calidad en una carrera técnica ocurre cuando dejas de ser quien descarga paquetes y te conviertes en quien los diseña.

El problema fundamental que resuelve NuGet no es simplemente “bajar DLLs”, sino la violación del principio DRY (Don’t Repeat Yourself) a nivel arquitectónico.
Imagina que tienes una clase AuditLog.cs o un StringUtils.cs. Al iniciar un nuevo microservicio, lo más “rápido” es copiar y pegar el archivo. Meses después, encuentras un bug crítico de seguridad en esa clase y debes parchear manualmente 10 repositorios distintos.

La solución profesional es empaquetarlo y vamos a descubrir cómo hacerlo con NuGet.

NuGet Library

Crear una librería no requiere magia, requiere metadatos. El archivo .csproj deja de ser un simple archivo de configuración para convertirse en el manifiesto del producto. Si el .dll es el producto, el .csproj es la etiqueta de envío; sin ella, nadie sabrá qué es, cómo se usa ni si es seguro.

Configuración básica

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFrameworks>netstandard2.0;net8.0</TargetFrameworks>
    <PackageId>MyCompany.Common</PackageId>
    <Version>1.0.0</Version>
    <Authors>Equipo de Arquitectura</Authors>
    <Company>Mi Empresa S.A.</Company>
    <Description>Librería base para validaciones y logs estandarizados.</Description>
    <PackageIcon>icon.png</PackageIcon>
    <PackageReadmeFile>README.md</PackageReadmeFile>
    <Deterministic>true</Deterministic>
    <PackageTags>logs;validation;common;architecture</PackageTags>
    <PackageOutputPath>./nupkg</PackageOutputPath>
    <RepositoryUrl>https://github.com/mi-empresa/my-common-lib</RepositoryUrl>
    <RepositoryType>git</RepositoryType>
    <PackageLicenseExpression>MIT</PackageLicenseExpression>
    <IncludeSymbols>true</IncludeSymbols>
    <IncludeSource>true</IncludeSource>
    <SymbolPackageFormat>snupkg</SymbolPackageFormat>
  </PropertyGroup>
</Project>

¿Por qué cada línea importa?

🎯 El dilema del Target (Multi‑targeting)

• netstandard2.0: corre en casi cualquier entorno (incluido .NET Framework 4.6.1+).
• net8.0: aprovecha optimizaciones modernas de rendimiento.
  NuGet entregará automáticamente la DLL correcta según el proyecto del consumidor.

📁 Assets (Icon & Readme)

• PackageIcon: incluye tu logo (PNG 128×128).
• PackageReadmeFile: el README.md se muestra en la pestaña de NuGet en Visual Studio, ofreciendo documentación inmediata.

🔒 Builds deterministas

Deterministic=true garantiza que, si el código no cambia, el binario sea idéntico bit a bit. Esto es crucial para validaciones de seguridad y cachés corporativas.

📦 Dependencias transitivas

Al declarar Serilog como PackageReference, cualquier consumidor de tu paquete lo recibirá automáticamente, evitando instalaciones manuales.

🏷️ Etiquetas de repositorio

RepositoryUrl y RepositoryType enlazan el paquete con su código fuente, aumentando la confianza y facilitando auditorías.

🗂️ Estrategia de versionamiento

Aunque aquí usamos una versión estática (1.0.0), en entornos profesionales se recomienda automatizarla con herramientas como MinVer, que generan versiones semánticas basadas en Git Tags.

⚖️ Licenciamiento legal

• Open Source: usa “ con identificadores estándar (MIT, Apache‑2.0, etc.).
• Propietario/Empresarial: usa “ apuntando a un archivo LICENSE.txt dentro del paquete.

NuGet Tools

Mientras que las librerías se integran en tu aplicación, los NuGet Tools son aplicaciones que se ejecutan junto a ella (p. ej., dotnet‑ef). Puedes crear tus propias herramientas corporativas empaquetando una aplicación de consola.

PackAsTool

La diferencia técnica radica en la propiedad PackAsTool, que indica a NuGet que el paquete contiene un ejecutable, no una librería.

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net10.0</TargetFramework>
    <PackAsTool>true</PackAsTool>
    <ToolCommandName>my-scaffolder</ToolCommandName>
    <PackageId>MyCompany.Scaffolder</PackageId>
    <Version>1.0.0</Version>
    <PackageOutputPath>./nupkg</PackageOutputPath>
  </PropertyGroup>
</Project>

Uso del tool

# Instalación global
dotnet tool install -g MyCompany.Scaffolder

# Ejecución
my-scaffolder "NuevoServicio"

💡 Para evitar la instalación global puedes usar Local Tools (dotnet new tool-manifest) y compartir la versión mediante dotnet tool restore.

Estrategias de distribución

Tener el artefacto .nupkg es solo el primer paso. La decisión crítica es dónde alojarlo. Para publicar, debemos registrar los destinos en nuestro NuGet.config. Este archivo actúa como una “libreta de direcciones” bidireccional: sirve tanto para consumir paquetes de feeds externos como para exponer los nuestros a otros equipos o a la comunidad.

(Continúa con la configuración de NuGet.config, publicación a nuget.org, Azure Artifacts, GitHub Packages, etc.)