If you use NuGet, and only check-in your packages.config files to source control, then your source control repository will stay smaller, and checkout faster. Checking in binaries is usually a nice thing to avoid. However, you need new developers to be able to get those libraries locally easily, and to allow your build server (continuous integration or otherwise) to keep libraries up to date.
After all, that’s one of the advantages of NuGet, you only download a new library when you first need it for that solution, or when you change versions.
In order to solve this problem, I use a rake task, as we use rake for other setup tasks (creating or seeding databases, continuous integration, etc). Rake may sound like an odd choice for a .Net environment, but it’s very good for customing cmd line tasks, and all the .Net building and setup we have run into can be done from the command line. Anyway, assuming the directory structure below, I thought I’d share the Rake tasks…
MySampleProject |-Rakefile |-tools |-NuGet.exe |-Source |-Packages |-NHibernate |-MassTransit |-SampleProject.Web |-packages.config |-SampleProject.Web.csproj |-other files, etc |-SampleProject.ServiceBus |-packages.config |-SampleProject.ServiceBus.csproj |-other files, etc
Relevant tasks in the Rakefile below. Note the ci task using nuget task before it builds.
def nuget_for_project(project_dir)
sh "tools\\NuGet.exe " +
"i Source\\#{project_dir}\\packages.config " +
"-o Source\\Packages"
end
namespace :nuget do
desc "nuget for servicebus"
task "ServiceBus" do
nuget_for_project "SampleProject.ServiceBus"
end
desc "nuget for web"
task "Web" do
nuget_for_project "SampleProject.Web"
end
desc "nuget for all"
task "all" => ["nuget:ServiceBus", "nuget:Web"]
end
desc "continuous integration task"
task "ci" => ["clean", "nuget:all", "build", "test"]
Comments
One response to “Rake Tasks For NuGet”
rake tutorial – http://docs.rubyrake.org/tutorial/index.html