El Bruno

Buenas,

this post is that I learn once and for all what is the Karma . Yesterday I I’m complaining a littleabout NuGet and today I already have explain what NuGet. As well, introductions to NuGet can be read here and hereIf you’re a webcast you can see this video. and Yes what happy life is read electronic books of paper, you can buy this Book: Pro NuGet .

If you still want the explanation of Bruno, the first thing that you have to understand is thatNuGet is not a Nugget, i.e. it is not this:

Well, if you’ve worked in Visual Studio you know that the subject of references in .net projects may be a little tricky. Personally I think that the thing until Visual Studio 2005 was very controladita; 99% of the items with which we were working were Ms, so there were no problems in searching for and adding items; But today with many elements that grow around VS at a very fast pace, since the subject of the references can be complicated.

Let’s look at an example; you if today you have to add the Entity Framework 5 references to your project, do know what?, and if you also want to work with a TT that allows you to create classes you little, do the references Add?. And if on top of all this, do you want to add a client for ASP.Net MVC WebAPI?, and deserialize JSON packages?

As well, NuGet is a repository of packages where for each product / scenario which they commented before, has a record of the required references. The repository (actually called Gallery) is in http://nuget.org, and is the site where you can download and install the packages you need.

Note: you can even create your own packages as explained here .

Let’s look at an example. Suppose I have a clean console application project. After the project is created it has only the Program.cs class and references are added by default.

If I need from this console application invoking JSON services created in an ASP.Net MVC WebAPI project, because the truth is o well I learn all assemblies that I need or am looking for something in the repository of NuGet . Deploying the shortcut menu from the folder references, select the option “Manage NuGet Packages”

In the form of packages of NuGet , select the option “OnLine” and look for “Microsoft.AspNet.WebApi.Client”. I can see that the first option are assemblies that I need.

As well, now to give the “Install” and see that it has happened in our project.

On the one hand, I see that you have added a couple of new references:

• Newtonsoft.JSON
• System.NET.http
• System.NET.http.formatting
• System.NET.http.WebRequest

and also added me the file “packages.config“. When you open the same content we can see that you have the following:

   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>

This file is determines which packets that our project is “installed” and then from the same references that you have downloaded and added to our project.

Speaking of references, some which have existential questions ask from where sorcho is taking these dlls?. Look, this is what we have in the project file:

   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>

Seems that the NuGet this has created a folder packages, a level above our project and it has downloaded all the necessary dlls. File Explorer gives us the reason.

Well, here already one there will be elucidated the advantages of NuGet . The main, well that with only 2 clicks have everything you need to work. There are other more complex and simple packages. There are other scenarios where for example, you need to make sure that all assemblies of a solution have the same reference to an Assembly. In this case NuGet is a fantastic help.

You can also choose to upload the Packages folder to the source code repository, and you ahorrarías some problems if the server is down for NuGet . You can create your own server package, if you work in a closed environment where your build server not accessible tohttp://nuget.org, etc etc etc.

There are many scenarios, and NuGet is one of the tools that deserve a round of applause as a closed solution to save us hours of organization and cleaning projects references

Saludos @ Home

El Bruno