Creating Nuget packages with Rake and Albacore

Creating a Nuget package is quite simple in theory and creating one manually can be done in a few minutes. But simple, repetitive tasks are easy to mess up and a tested build script will never include the wrong config file because it was thinking about coffee and cinnamon buns. Besides who wants to do this by hand every release, it’s a perfect task to be automated.

I helped to change FluentMigrator’s packaging script to create a Nuget package a while ago, so I’ll use that to illustrate how to create a Nuget package with Rake and Albacore.

All Nuget packages need a nuspec file and there are two ways to script this. The first way is to just create a nuspec file manually and then update the version with the build script. Nancy uses this approach, see here. They parse the nuspec files with an XML parser to find the right nodes, such as version, to update. Nancy has a lot of packages so they search after nuspec files and create a package when they find one. With FluentMigrator we only have two packages so I used Albacore and the Nuspec task to create the nuspec file:

desc "create the FluentMigrator nuspec file"
  nuspec :create_spec do |nuspec|
     version = "#{ENV['version']}" = "FluentMigrator"
     nuspec.version = version.length == 7 ? version : FLUENTMIGRATOR_VERSION
     nuspec.authors = "Josh Coffman"
     nuspec.owners = "Sean Chambers"
     nuspec.description = "FluentMigrator description which is really long."
     nuspec.title = "Fluent Migrator"
     nuspec.language = "en-US"
     nuspec.projectUrl = ""
     nuspec.working_directory = "packages/FluentMigrator"
     nuspec.output_file = "FluentMigrator.nuspec"

The only bit of logic here is for setting the version. There is a default version defined as constant but this can be overwritten by passing in a command line parameter.

FluentMigrator has a working directory for packaging where I copied in the files to be included in the Nuget package. Nuget uses conventions for the directory names in the working directory. The three conventions are:

  1. libfor the assembly references to be installed into the target project,
  2. toolsfor the command line tools and powershell scripts and
  3. content for files that are copied into the root of the target project.

The main FluentMigrator package only uses lib and tools. Lib contains two subdirectories one for .NET 3.5 and one for 4.0. So the FluentMigrator dlls are copied into the appropriate lib subdirectories, the .NET 3.5 dll into lib\35 and the 4.0 dll into lib\40. Into the tools directory go all the different runners: the command line runner, the MSBuild runner and the Nant runner as well as all the dlls for the supported sql providers.

Then you just need to run the Nuget command line and call the pack command to create a nupkg file:

def nuget_pack(base_folder, nuspec_path)
    cmd =
    output = 'nuget/'
    cmd.command = 'tools/NuGet.exe'
    cmd.parameters = "pack #{nuspec_path} -basepath #{base_folder} -outputdirectory #{output}"

There is an Albacore task for this but I’ve gone with the Exec task instead here.  And this is called like this:

nuget_pack('packages/FluentMigrator/', 'packages/FluentMigrator/FluentMigrator.nuspec')

So to recap; the script creates a nuspec file, copies in the relevant files into the convention based working directory and then finally calls NuGet.exe with the pack command to create a Nuget package.

Pretty easy so far, it did get a bit more complicated building the second FluentMigrator package that is dependent on the first package. But I’ll leave that for another post.

Learning New Web Frameworks

As a .NET programmer a lot of my professional life is focused on ASP.NET MVC and Webforms but outside of my little Microsoft bubble there is a lot development happening with new and existing web frameworks. So this blog post is a To Do list to remind me of what I need to learn in the coming months.  And hopefully it will provide some interesting links for other .NET web devs.

The first two on the list are the most hyped web frameworks in the programming world right now, Ruby on Rails and Sinatra.

Ruby on Rails is probably the main reason that ASP.NET MVC exists as it forced Microsoft to build something better than Webforms. Learning Ruby on Rails is probably what will occupy most of my designated learning time in the near future as it also entails learning a new programming language, Ruby. Ruby on Rails will really challenge some of my assumptions about how to build a website. I had pretty much discounted ever using the Active Record pattern for data access but Rails seems to use it in a way that works. Not only that but it uses the Active Record classes as persistent view models which is totally contrary to best practices in the .NET world. But the Ruby language’s dynamic nature seems to make the whole architecture work really well. See Hadi Hariri’s blog post about what the M in MVC is if you use ASP.NET MVC . It seems like a lot of .NET devs are looking at Rails code and questioning their C# code.

I am using a mixture of Ruby Koans and The Ruby Programming Language book to get myself started with Ruby. I just completed the Rails for Zombies tutorial which is a well-polished, light introduction to Rails programming; recommended if you just want to dip your toe in to Rails. I just starting reading the rails tutorial (thanks for the tip, Petter Wigle!)

I’ll be looking to buy a Rails book soon and am thinking about Agile Web Development with Rails. Anyone got any recommendations?

Another reason to learn Rails is its open source ecosphere which is much larger and more developed than .NET’s and will hopefully be a source of ideas for my .NET work as well. Just look at the amount of Ruby clones popping up in the .NET open source community and some of these clones really fill needs that are not being filled by Microsoft. On a side-note I really recommend FluentMigrator which is a clone of Ruby on Rails database migrations.

Sinatra has generated a lot of hype as well during the last two years. It is a web framework that has a totally different philosophy to all the frameworks I’ve worked with. It aims to be a simple DSL for creating web applications as quickly as possible. It looks to be very elegant and something that sounds very useful in certain situations.

There has recently been a sudden increase in the number of web frameworks in the .NET world. The most interesting one is Manos de Mono built by Jackson Harper from the Mono Moonlight team. The main features are its own built in high performance web server that can handle thousands of connections (perfect for long running applications with persistent connections, the Twitter web client is the perfect example), simpler routing than ASP.NET MVC, a templating engine with HTML5 boilerplate templates and that everything is mockable for easy testing.

I’ll also be taking a look at two new competing .NET Sinatra clones, Nancy and Nina. I can see myself using one of these for simple web services. I’ll also be trying out MonoDevelop instead of Visual Studio while developing with these. It will be interesting to see just how much I miss Resharper.

Another framework on my list is Knockout, a MVVM Javascript framework written by Steve Sanderson. And finally Moncai, a Heroku for .NET looks really interesting. The .NET world really needs an easy way to deploy web applications in the same way that Ruby developers can with Heroku. AppHarbour is another new hosting service that I want to try out as well. I did think about having a look at FubuMVC and Monorail as well but I have to set a limit somewhere.

And the end product of all this exploration will be some sort of web app (or maybe even several web apps). My own blog engine is one option (just like my colleague Johan) as I could then host my this blog myself. Whatever it turns out to be I’ll let you know.