El Bruno

Buenas,

este post es para que aprenda de una vez por todas lo que es el Karma. Ayer me quejo un poco sobre NuGet y hoy ya me toca explicar qué es NuGet. Pues bien, introducciones a NuGet se pueden leer aquí y aquí; si sos de WebCasts podes ver este video. y si lo que te alegra la vida es leer libros electrónicos de papel, te podes comprar este libro: Pro NuGet.

Si todavía queres la explicación del Bruno, lo primero que tenes que entender es que NuGet no es Nugget, es decir no es esto:

Ahora bien, si has trabajado en Visual Studio sabrás que el tema de las referencias en proyectos .Net puede llegar a ser un poco delicado. Personalmente pienso que hasta Visual Studio 2005 la cosa estaba muy controladita; el 99% de los elementos con los que trabajábamos eran de MS, con lo que no había problemas en buscar y agregar elementos; pero hoy con tantos elementos que crecen alrededor de VS a un ritmo muy rápido, pues el tema de las referencias puede complicarse.

Veamos un ejemplo; si hoy tienes que agregar las referencias de Entity Framework 5 a tu proyecto, ¿sabrías cuales son?, y si además quieres trabajar con un TT que te permita crear clases POCO, ¿qué referencias agregarías?. Y si encima de todo esto, ¿quieres agregar un cliente para ASP.Net MVC WebAPI?, ¿y deserializar paquetes JSON?

Pues bien, NuGet es un repositorio de paquetes donde para cada producto / escenario de los que comenté antes, se tiene un registro de las referencias necesarias. El repositorio (en realidad se llama galería) está en http://nuget.org, y es el sitio desde donde te puedes descargar e instalar los paquetes que necesites.

Nota: inclusive puedes crear tus propios paquetes como se comenta aquí.

Veamos un ejemplo. Supongamos que tengo un proyecto de aplicación de consola limpia. Una vez creado el proyecto posee solo la clase Program.cs y las referencias por defecto que se agregan.

Si desde esta aplicación de consola yo necesito invocar a servicios JSON creados en un proyecto ASP.Net MVC WebAPI, pues la verdad es que o bien me aprendo todos los ensamblados que necesito o busco algo en el repositorio de NuGet. Desplegando el menú contextual desde la carpeta referencias, selecciono la opción “Manage NuGet Packages”

En el formulario de paquetes de NuGet, selecciono la opción “OnLine” y busco por “Microsoft.AspNet.WebApi.Client”. Puedo ver que la primera opción son los ensamblados que necesito.

Pues bien, ahora a darle al “Install” y veamos que ha pasado en nuestro proyecto.

Por un lado veo que ha agregado un par de referencias nuevas:

• Newtonsoft.Json
• System.Net.Http
• System.Net.Http.Formatting
• System.Net.Http.WebRequest

y además me ha agregado el archivo “packages.config”. Cuando abrimos el contenido del mismo podemos ver que tiene lo siguiente:

   1: <?xml version="1.0" encoding="utf-8"?>

   2: <packages>

   3:   <package id="Microsoft.AspNet.WebApi.Client" version="4.0.20710.0" 

   4:            targetFramework="net40" />

   5:   <package id="Microsoft.Net.Http" version="2.0.20710.0" 

   6:            targetFramework="net40" />

   7:   <package id="Newtonsoft.Json" version="4.5.8" 

   8:            targetFramework="net40" />

   9: </packages>

Este archivo es el que determina los paquetes que tiene “instalado” nuestro proyecto y luego a partir del mismo, las referencias que se ha descargado y agregado a nuestro proyecto.

Hablando de referencias, alguno que tenga dudas existenciales se preguntará ¿de dónde sorcho está sacando estas dlls?. Pues mira, esto es lo que tenemos en el archivo de proyecto:

   1: <ItemGroup>

   2:   <Reference Include="Newtonsoft.Json">

   3:     <HintPath>..\packages\Newtonsoft.Json.4.5.8\lib\net40\Newtonsoft.Json.dll</HintPath>

   4:   </Reference>

   5:   <Reference Include="System" />

   6:   <Reference Include="System.Core" />

   7:   <Reference Include="System.Net.Http, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL">

   8:     <HintPath>..\packages\Microsoft.Net.Http.2.0.20710.0\lib\net40\System.Net.Http.dll</HintPath>

   9:   </Reference>

  10:   <Reference Include="System.Net.Http.Formatting, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL">

  11:     <HintPath>..\packages\Microsoft.AspNet.WebApi.Client.4.0.20710.0\lib\net40\System.Net.Http.Formatting.dll</HintPath>

  12:   </Reference>

  13:   <Reference Include="System.Net.Http.WebRequest, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL">

  14:     <HintPath>..\packages\Microsoft.Net.Http.2.0.20710.0\lib\net40\System.Net.Http.WebRequest.dll</HintPath>

  15:   </Reference>

  16:   <Reference Include="System.Xml.Linq" />

  17:   <Reference Include="System.Data.DataSetExtensions" />

  18:   <Reference Include="Microsoft.CSharp" />

  19:   <Reference Include="System.Data" />

  20:   <Reference Include="System.Xml" />

  21: </ItemGroup>

Parece que el NuGet este ha creado una carpeta packages, un nivel por encima de nuestro proyecto y en el mismo ha descargado todas las dlls necesarias. El File Explorer nos da la razón.

Bueno, hasta aquí ya alguno habrá dilucidado las ventajas de NuGet. La principal, pues que con solo 2 clicks tengo todo lo necesario para trabajar. Hay paquetes simples y otros más complejos. Hay otros escenarios donde por ejemplo, necesitas asegurarte que todos los ensamblados de una solución posean LA MISMA REFERENCIA a un ensamblado. En este caso NuGet es una ayuda fantástica.

También puedes optar por subir la carpeta Packages al repositorio de código fuente, y te ahorrarías algunos problemas si está caído el server de NuGet. Puedes crear tu propio servidor de paquetes, si trabajas en un entorno cerrado donde tu servidor de compilación no puede acceder a http://nuget.org, etc etc etc.

Hay muchos escenarios,y NuGet es una de las herramientas que se merecen un aplauso como solución cerrada para ahorrarnos horas de organización y limpieza de referencias en proyectos 

Saludos @ Home

El Bruno