Domina el uso de paquetes NuGet en .NET

Source: Dev.to

¿Qué es realmente NuGet?

Imagina que NuGet es el Amazon o Mercado Libre de .NET. Tú no fabricas cada tornillo de tu mueble; los pides a la tienda.

• El Package: Es el producto que compras (Newtonsoft.Json, EntityFramework).
• El Source (Feed): Es el almacén o la tienda donde se guardan los paquetes.

¿A dónde van mis paquetes?

Muchos desarrolladores creen que cuando ejecutan dotnet restore, las DLLs mágicamente aparecen en su proyecto. Entender el flujo real es vital para saber qué está pasando por detrás:

Request: Tu proyecto (.csproj) pide Newtonsoft.Json v13.0.1.
Restore: NuGet busca en los Sources configurados.
Global Packages Folder: NuGet descarga y descomprime el paquete en una carpeta global de tu usuario (generalmente %userprofile%\.nuget\packages en Windows o ~/.nuget/packages en Linux/Mac). No se guardan dentro de tu proyecto.
Build: Cuando compilas, .NET lee las DLLs de esa carpeta global y las copia a tu carpeta bin/Debug o bin/Release.

¿Por qué importa esto? Porque optimiza el espacio. Si tienes 10 proyectos usando la misma librería, solo se descarga una vez en tu disco duro.

La jerarquía de configuración

Antes de escribir una sola línea de configuración, debes entender cómo piensa NuGet. Cuando ejecutas un restore, no solo mira tu proyecto. NuGet combina configuraciones en cascada siguiendo una jerarquía estricta:

• Nivel Máquina: A menudo este archivo ni siquiera existe físicamente o está vacío, a menos que un administrador lo haya puesto ahí.
• Nivel Usuario: Este es el más común (%appdata%\NuGet\NuGet.Config) y suele acumular mucha “basura digital” con el tiempo.
• Nivel Directorio (Recursivo): NuGet busca en la carpeta de tu solución… pero si no encuentra lo que busca, sube a la carpeta padre, y luego a la del abuelo, hasta llegar a la raíz del disco.

El origen del “En mi máquina funciona” 🤷‍♂️

Aquí nace el famoso meme. Imagina que tú tienes configurado un feed privado en tu Nivel Usuario porque trabajas en varios proyectos de la empresa. Creas un proyecto nuevo y compila perfecto. Tu compañero clona el repositorio, intenta compilar y… error.

¿Por qué? Porque tu proyecto está dependiendo de una configuración invisible que vive solo en tu usuario. Para tu compañero, ese feed no existe.

Detectar la configuración activa

Ejecuta el siguiente comando en la carpeta de la solución:

dotnet nuget list source

Este comando muestra la lista final y combinada de todos los orígenes que NuGet está usando realmente en esa carpeta. Si ves rutas que no reconoces o servidores apagados, es culpa de la herencia.

NuGet.config

Crear un archivo NuGet.config explícito en la raíz de tu solución rompe la cadena de herencia tóxica y asegura que el proyecto funcione para todos.

  
     elimina toda la "basura" heredada del usuario o máquina -->
    

    
    

    
    

    
    

    
    
  

  
  
    
  

  
    
    
      
      
    
  

Beneficios de esta configuración

• 🛡 Aislamiento: Con “ proteges tu proyecto de configuraciones globales rotas.
• 🛠 Independencia: Un nuevo desarrollador solo necesita git clone y dotnet restore.
• 🔄 CI/CD Friendly: Los pipelines saben exactamente dónde buscar sin pasos extraños.

El caos de la prioridad

Si tienes configurado nuget.org y GitHubFeed, y ambos contienen un paquete llamado Newtonsoft.Json, ¿cuál se descarga?

NuGet actúa “al primero que responda”, lo que implica dos riesgos:

1. Rendimiento: Busca tu paquete privado en la tienda pública antes de encontrarlo.
2. Seguridad: Un atacante podría subir un paquete malicioso a nuget.org con el mismo nombre que tu paquete interno (ej.: MiBanco.Core). Tu proyecto podría descargar el paquete del atacante sin que lo notes. 🚨