NuGet - download packages from the Internet during the assembly process

UPD: A method similar to that used here is included with NuGet 1.6 . Accordingly, the article is outdated.

One of the things I've always liked about Java is Maven. One file with a list of everything you need, and no binaries in the repository. When NuPack appeared, I decided - hurray, here it is, happiness came to our street. But it was not there. NuPack provided a convenient interface for working with packages ... but without the ability to normally screw into the build process.

I poked it then, looked, but I didn’t see any real benefit. It does not hurt a lot of help to download packages by name with manual powershell commands. Well, yes, it’s more convenient than downloading FIGs from where, and even adding references with your hands, but I don’t need it every day. In general, the game is not worth the candle.

But one day I realized that I need to do something with the Shared \ Bin folder in my access control, because it is already incredibly swollen. I decided to look if something had changed with NuPack, which was already called NuGet. No, things are going on there .

But nuget.exe got an interesting feature ...
If you pass it the “packages.config” file as a parameter, in which NuGet stores the list of packages installed in this project, then it will download all the packages specified in it!

Matter of technology

1) We create NuGet.Targets, which we will include in our projects:



 
  
   _InsallNuGetPackages;$(BuildDependsOn)
  
 

 
 
 


* This source code was highlighted with Source Code Highlighter.

We put it in sorts control, it will launch NuGet before each build. Regarding the placement of NuGet: you can put the exe-box in the control next to the target, you can simply add it to path. The first option, as for me, is more convenient, although less kosher. If you prefer to force all employees to install Nuget.exe in Path - just remove it $(MSBuildThisFileDirectory).
... Do not forget about the build servers;)

2) Add packages to the NuGet project.
3) Add hands to the *. * Proj file:



* This source code was highlighted with Source Code Highlighter.

Actually, all packages will be pulled out automatically when building. And only if they are not there yet - which is good.

What if...

... my project uses binaries that are not on nuget.org? Not a problem. Create your feed. You can use MyGet , but in my opinion it is even easier to create on your server:
1) Create a new Empty Web Application Project
2) Put the NuGet.Server package on it
3) Publish.

All is ready. You can clean it up a bit, because garbage is published ... Well, as usual. In the published project, there will be a Packages folder, where we actually put our packages.

Cooking a side dish .

This is also easy. nuget.exe to help you.
In turn:
1) will nuget spec имя.пакетаgenerate a file with the nuspec extension containing the package manifest template. We correct it, it is trivial, you will figure it out yourself :)
2) We put our nuspec in an empty folder, create a lib next to it, put our dll in it.
Run nuget pack имя.пакета.nuspecthat will generate the package file.
3) Pour the received package onto the server, in the aforementioned Packages folder.

Regarding the daddy lib: the files found in it will be added to References in the importing project. And only so. This was not clearly described in the documentation, so I needed to experiment.

Finishing touch

So, we have a server with packages ready, we need to fasten it to the studio and build process. In the studio - again, no problem:
Tools-> Library Package Manager-> Package Manager Settings, select Package Sources, add your own. But what am I actually - if you have already read to this place, then you’ll figure it out.
Build process: to be honest, I was hoping that NuGet would store the package path from Package files. But no, he does not fall to such trifles. I have to add parameters for nuget.exe ... Remember, I made it run in a separate file? A lot of honor for one line, right? No it is not true. Now it’s useful to us (as it came in handy for me not to climb 30 separate projects). Change the line from exec to the following:



* This source code was highlighted with Source Code Highlighter.

The order of sources is just this - in which case it will be possible to replace some version from the official repository with your own patched one (for example, I have this with AjaxControlToolkit).

... Congratulations, now you can safely remove the Shared \ Bin monster, commit and enjoy the cleanliness in the sorts control.