You know what? I could really use a package manager!

So last night, I had a real itch to start experimenting with some new technologies coming out in the .NET space. After some going back and forth thinking how I should approach it, I decided that rather than trying to write yet another fake application that I wouldn't finish, I will just fork one of my favorite sample project instead. That way, starting with a well designed application in place and I can replace the relevant layers with the new technologies I am interested in. I get to skip wasting time on code I already know while still learning from something more complex than a "Hello World" demo.

But first thing's first, I want to upgrade the solution to VS 2010 and .NET 4.0. Simple enough right? WRONG! The Microsoft stack is pretty painless to update. A few clicks through a conversion wizard and all the projects are saved in the new format. And then things quickly spiraled out of control from there.

This shouldn't really be a surprise to anybody who use a lot of open source libraries in their projects. Once every few months, we open source addicts will go through a cycle of DLL upgrade hell. Generally triggered by the burning desire to grab the latest release of tool X for a shiny new feature that we just couldn't live without, and it quickly descends into chaos.

Here's how it went down. I first discovered something is not quite clicking when I couldn't start the web application. Broken app = signs of trouble, couldn't be any more obvious. I quickly realized that .NET 4.0 comes with ASP.NET MVC 2, which means I need to upgrade to the newer MvcContrib project.

Some googling, a bit of reading and 15 minutes later, I downloaded and copied over the new MvcContrib assemblies. Compiled and off we go ... not so fast. The compiler was not happy, complaining that Castle.Windsor is outdated. Sigh!

Some more googling, and a couple clicks later, I landed on Castle project's homepage. OK, Downloading the latest now ... but hold on, that version is a bit too new! After some more digging and reading, the right version is copied over. The compiler must be happy now ... Not quite. Rhino.Commons is feeling left out of the party and wants a tune up too. Needless to say, frustration built up quickly. After over an hour of searching and downloading, I decided to throw in the towel and live to upgrade another day.

While walking away, I thought to myself, "you know what? I could really use a package manager!" Then the sky will be blue, the grass will be green and there will be world peace. If only we had something like RubyGems for .NET.

Today, with that lingering thought my my head, I googled for ".NET package manager". I kept my expectations low because surely if there was one, the world would've known. First few pages of the search results confirmed my fear - lots of blog discussions and a few dead projects that never got off the ground. I wasn't ready to gave up just yet however. How about "RubyGems for .NET", I know, sounds crazy, right? And what do you know, looks like there is a NU kid on the block. The project is not even a month old. Someone has done the unthinkable!

Much excitement ensues. Let's see if it will play well with IronRuby, which I already have installed.

I don't know what "thor" is, but that seemed to have gone well. Now let's try to bring down a real package.

Not as smooth. Somewhat ironic that I'm running into an outdated dependency error, but that was easily resolved by a quick self-upgrade. After that, we are really jamming! Gems ... get it? So clever!

A peek in windows explorer, you will see all the necessary dependencies downloaded and copied to the project folder with just a few simple commands.

Compare this to the hours I spent hunting down assemblies by hand, call me impressed. RubyGems + NU definitely fills a void in my arsenal. Couple that with a symbol server, developing with open source tools just became that much easier. I hope the community will embrace it. It definitely has my support.