UPD: A method similar to that used here is included with the NuGet 1.6 package. Accordingly, the article is outdated.
That's what I always liked in Java, it's 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 has come to our street. But it was not there. NuPack presented a convenient interface for working with packages ... but without the possibility of normally screwing into the build process.
I picked it up then, I looked, but I didn’t see any real benefit. It does not hurt much help - to download packages by hand with manual powershell commands. Well, yes, it is more convenient than downloading FIGs to know where, and even add 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 needed to do something with the Shared \ Bin folder in my sorts-control, because it was already incredibly swollen. I decided to take a look, has anything changed with NuPack, which already became NuGet? No, who
and further there .
But nuget.exe has an interesting feature ...
If you pass the “packages.config” file as a parameter in which NuGet stores the list of packages installed in this project, it will download all the packages specified in it!
The case of technology
1) Create NuGet.Targets, which we will include in our projects:
<? xml version ="1.0" ? >
< Project xmlns ="http://schemas.microsoft.com/developer/msbuild/2003" >
< PropertyGroup >
< BuildDependsOn >
_InsallNuGetPackages;$(BuildDependsOn)
</ BuildDependsOn >
</ PropertyGroup >
< Target Name ="_InsallNuGetPackages" >
< Exec Command ="$(MSBuildThisFileDirectory)\NuGet install $(ProjectDir)packages.config -o $(SolutionDir)Packages" />
</ Target >
</ Project >
* This source code was highlighted with Source Code Highlighter .
We put it in sorts-kontrol, it will launch NuGet before each build. Regarding the placement of NuGet: you can put an exe-shku in sorts-control next to the target, you can simply add to the path. The first option, as for me, is more convenient, although less kosher. If you prefer to force all employees to put Nuget.exe in the Path - just remove
$(MSBuildThisFileDirectory)
.
... Do not forget about build servers;)
2) Add packages to the NuGet project.
3) Add your hands in the *. * Proj file:
< Import Project ="$(SolutionDir)\\\\\NuGet.Targets" />
* This source code was highlighted with Source Code Highlighter .
Actually all the packages will be pulled out automatically during the build. And only if they are not there yet - which is good.
What if...
... do I use binaries in my project, which is not on nuget.org? No problem. Create your feed. You can use
MyGet , but in my opinion it’s even easier to create on your server:
1) Create a new Empty Web Application Project
2) Put the package NuGet.Server on it
3) Publish.
All is ready. You can clean up a bit, because the garbage is published ... Well, as usual. In the published project will be the Packages folder, where we actually fold our packages.
Cooking garnish packages.
This is also easy. nuget.exe to help you.
Take turns:
1)
nuget spec .
generates a file with the nuspec extension containing the package manifest template. We correct it, it is trivial, you will figure it out :)
2) Put our nuspec in an empty daddy, create a lib next to it, put our dll in it.
Run the
nuget pack ..nuspec
, which will generate the package file.
3) Fill the received package on the server, in the above-mentioned Packages folder.
Regarding daddy lib: 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 it was necessary to experiment.
Finishing touch
So, we have a server with packages ready, we need to tie it to the studio and the build process. In the studio - again, no problem:
Tools-> Library Package Manager-> Package Manager Settings, select Package Sources, add your own. What is it I actually - if you have read this far, then you will understand.
Build process: to be honest, I was hoping that NuGet would be stored in Package files and where to download from. But no, he does not go down to such trifles. You have to add parameters for nuget.exe ... Remember, I took out its launch in a separate file? A lot of honor for one line, right? No, it's not true. Now it will be useful to us (as it came in handy to me, so as not to climb 30 separate projects). Change the line from exec to the following:
< Exec Command ="NuGet install $(ProjectDir)packages.config -o $(SolutionDir)Packages -Source nuget.example.com/nuget -Source go.microsoft.com/fwlink/?LinkID=206669" />
* This source code was highlighted with Source Code Highlighter .
The order of the sources is exactly this - in which case it will be possible to replace some version of the official repository with its own patched one (for example, in my case with AjaxControlToolkit).
... Congratulations, you can now safely remove the Shared \ Bin monster, commit and enjoy the cleanliness in Sort Control.