Unicorns, Triple Rainbows, Package Management and Lasers
Since the dawn of time, developers have been adding references to projects.
Even longer, they’ve been doing it through a cumbersome and tedious manual process.
You know the routine. C’mon. Play along with me:
- Launch web browser
- Search for the website for the library you want to add
- Hunt down the latest version of said library
- Download to your local drive
- Extract files to some forgotten location
- Copy files to your solution directory
- Add references to your project(s)
- Lather, Rinse, Repeat
It’s ugly. And it’s something every developer does almost every day (at the very least, once at the beginning of a project).
Brothers and sisters, I say stop the insanity! Lay down those manual processes for shiny happy new and improved ones. Embrace the future now. Embrace NuPack!
A Brief History of Time
The lather, rinse, repeat scenario has been one dogging developers forever. A couple of years ago there were discussions about .NET package management in various corners around the universe. I remember event talking about it in a fishbowl session during ALT.NET Calgary and there was a lot of interest back then, but no solution. In the .NET universe there’s plenty of code out there and some of it is even good (not mine). To paraphrase Sebastien Lambla:
Finding great .NET code is easy. Using it and managing all the dependencies that can exist between packages is not.
What’s a developer supposed to do trying to get the right version without going through the geek junk punch each and every time? The Ruby world has had RubyGems, a standard for publishing and managing third party libraries, since 2003. Package management is no stranger to the Linux world. It was one of the key things that made me switch to Debian a few years back with it’s Advanced Package Tool (Apt) system of delivering applications and keeping them up to date.
There have been so many kicks at the can with this problem and .NET with some being very successful and others being just vaporware. I won’t get into details on each of them but feel free to check out OpenWrap, Hornget, and NPackage to get started on alternatives.
The Nu Kid on the Block
A few months ago I personally stumbled over Rob Reynolds post about Nu. It was cool. Within hours of downloading and installing it I was creating gems and writing blog posts and telling the world how great Nu was and how I wanted to make love to it. I became deeply entrenched with Nu simply because it worked and solved a problem. It was easy, low friction (get over the Ruby install .NET developers, we’re better than that!) and other people seemed to like it. Since then we got a new wiki going, new releases were coming out, improvements were being made, and I was a little gem producing machine. Life was good.
Around that time I was also approached by Microsoft about a double-secret-probation project that they were looking for feedback on. Together with Rob Reynolds, Dru Sellers, and Eric Hexter we spent the next few weeks collaborating together with Microsoft directly on NuPack.
NuPack
NuPack is an open source, integrated package management tool for adding libraries and tools to your .NET projects. It is available as a command line tool, integrated console window inside of Visual Studio 2010, a UI element in the Visual Studio context menu, and a series of PowerShell cmdlets. NuPack is a concerned with adding features to an existing application. For the most part, it automates the steps that developers take today to get a library into their source tree.
One key goal is that after installing a project into an application, the developer can commit changes to their source control repository, another developer can get latest, and continue to develop. For the most part, NuPack works with the source files for building a site, not the output of those files. Contrast this to a traditional package management system which is focused on automating the process of installing, upgrading, configuring, and removing software packages from a computer.
Open Source FTW!
Microsoft is no stranger to Open Source. There are so many great examples of Open Source in the Microsoft space like ASP.NET MVC, NerdDinner, the Silverlight Toolkit, and other releases that the ASP.NET team is working on. However while the source code for these projects is available to download, in most cases the projects are run and contributed by Microsoft staff. They’re just not the same as NuPack.
NuPack breaks some exciting ground and heralds a new era in open source and Microsoft. NuPack is the first collaborative effort between open source developers working side by side with Microsoft developers David Ebbo, David Fowler (and others) herded up by Phil Haack (with Scott Hanselman doing Jazz Hands) and Scott Guthrie as The Beaver. This is the first project where open source geeks like you and me can collaborate with softies on something that is core to the Microsoft development line, namely Visual Studio.
Package management for .NET is here. It’s cool (waaaaay cooler than double rainbows and even better than those oh so rehashed triple ones too). It’s integrated with Visual Studio in a variety of ways. Most of all, it’s drop dead easy, even for a simpleton like me.
Getting The Goods
Right now NuPack comes in the form of a Visual Studio Extension. Once you download it double click on the NuPack.Tools.vsix file and you’ll see something like this:
Note: You don’t need a specific flavor of Visual Studio 2010 here but the NuPack extensions only works with Visual Studio 2010. I’m just kind of an “ultimate” sorta guy.
Click Install and the extension will be added to Visual Studio 2010. Restart any Visual Studio instances you have running. Once Visual Studio restarts, click on Tools > Extension Manager and you should see NuPack Tools installed:
NuPack comes in three forms of entertainment for your development pleasure. A special Visual Studio console window (NuPack Console) where you use PowerShell to interact with NuPack, a command line tool, and a GUI built right into Visual Studio.
NuPack Console
The NuPack Console is an alternate way to access the package management system instead of the Package Manager Gallery UI. The NuPack Console is exposed as a tool window inside of Visual Studio and uses PowerShell cmdlets to access the same features that the GUI does.
Just type in the cmdlet name to add packages to solutions, install new packages, and getting lists of packages. The package manager console is a quick way to buff your project up with third party solutions quickly.
Check out the Package Manager Console Command reference here on the wiki.
Visual Studio Integration
If you’re not hip on using PowerShell and do the gooey thing then there’s integration too. Right click on the References folder in a project and you’ll see this:
Hey. Add Package Reference is sort of new, isn’t it? Click on it and you’ll see something like this:
Packages are the basic building blocks of NuPack and are made up of all the files that will get installed when you a add a package to a solution (assemblies, text files, scripts, etc.). It can also contain instructions to execute when the package is installed.
A package source is a place where you can find NuPack packages. We have a default one setup already that is included with NuPack so there’s nothing you need to do to use it. Once you install NuPack, you’ll have access to all the packages there.
If you’re looking to change the package source or adding your own (see information below about setting up your own) then inside of Visual Studio click on Tools > Options. After installing NuPack you’ll see a new node in the options tree, Package Manager. Under the General settings you can see a list of package sources. These are the sources that NuPack will look through to find packages and present them in the Gallery or via the List-Packages cmdlet.
From the gallery you can select a package and install it. It will immediately be added to the current solution. Any existing packages are listed here and you can remove or update them through the UI.
Command Line Junkies
Finally for those that just need to launch that command line you can use the nupack.exe console application. The nupack.exe is a console application that will create new packages for you. Just construct a manifest file (sample below on this), get the files together that you want to include in your package, and from the command line type “nupack.exe yourmanifestfile.nuspec”.
Here’s an example:
Under the Covers
NuPack is pretty basic in how it works. A package is created from two things:
- The contents of the package (assemblies, etc.)
- Meta data about the package
The meta data is a simple xml file with a .nuspec extension. For example here’s the .nuspec for MVCTurbine:
<?xml version="1.0" encoding="utf-8"?>
<package>
<metadata>
<id>MVCTurbine</id>
<version>2.1</version>
<authors>
<author>Javier Lozano</author>
</authors>
<description>MVC Turbine is a plugin for ASP.NET MVC that has IoC baked in and auto-wires controllers, binders, view engines, http modules, etc. that reside within your application. Thus you worry more about what your application should do, rather than how it should do it.</description>
<language>en-US</language>
</metadata>
</package>Very simple to create and includes some basic information like the author of the tool, a description, and the version number.
When a request is made to the package source, NuPack will find the contents of the package and do it’s magic adding it to your project and solution. How does it handle dependencies? Very similar to how RubyGems does using additional properties in the .nuspec file. Here’s the .nuspec for the Ninject adapter for MVCTurbine:
<?xml version="1.0" encoding="utf-8"?>
<package>
<metadata>
<id>MvcTurbine.Ninject</id>
<version>2.1</version>
<authors>
<author>Javier Lozano</author>
</authors>
<description>Ninject support for MVC turbine.</description>
<language>en-US</language>
</metadata>
<dependencies>
<dependency id="MVCTurbine" version="2.1" />
<dependency id="Ninject" version="2.0" />
</dependencies>
</package>As you can see, there is an additional node in the Xml file, dependencies. Each dependency has an id and a version. This is matched up to the <id> node in the original .nuspec for that package and if found, downloaded. So if you add MvcTurbine.Ninject to your project it will automatically locate and pull down MVCTurbine (in this case version 2.1) and Ninject. You don’t have to worry about hunting down all those dependencies because that what the creator of a package does for you. As a consumer, you just want to use a tool so the package manager takes care of that for you.
More information about the NuSpec File Format can be found here on the site.
DIY Package Management
Hey, want to run your own server? Knock yourself out. A package source can be any place where you get NuPack packages from. This can be as simple as a directory or network share.
- Setup a file share that everyone has read access to
- xcopy deploy a bunch of .nupkg files
- Install NuPack.vsix
- Point the package source at your share
- Hilarity ensues
Yes kids, you don’t need a WOPR computer to host your own packages. Just drop them on a file share and tell NuPack where to find them. No server needed (the package source can even just be as simple as “C:\My Amazing Packages That Are Going To Rule The World”).
Is it Evil?
Does NuPack solve world hunger? No. Does it address every concern every developer has around package management? Absolutely not. There are always going to be questions and problems and places to explore. There’s no such thing as a silver bullet (or the Easter bunny for that matter, sorry to burst that bubble). The difference is that the exploration doesn’t need to be done in a vacuum and Microsoft is committed to making this easy for you.
Transparency is a good thing, it lets us see things from different perspectives and we all know developers have more opinions than USB keys. The more eyes looking at something, the more opportunities there are to find flaws, course correct, and evolve the product to a better place.
For me, I will still continue to build gems for Nu while I’m building packages for NuPack. Think of NuPack as evolution. We deliberately named it “NuPack” to symbolize a sort of merging of some of the concepts of Nu and principles we hold with Nu, together with the package manager Microsoft started.
Along with the other team members, we’re contributing to the documentation effort for NuPack on the Wiki site and enhancing the features of the product so that new developers have a good, solid understanding of how this beast works and meeting the needs of managing third party dependencies.
Elsewhere in the Universe…
Go download it and install it. Now.
More information can be found on the CodePlex site about NuPack including:
- Getting Started Guide – Everything you always wanted to know about NuPack to start your day
- Frequently Asked Questions – Well, every project has to have one of these don’t they?
- Creating a Package – Start building yours today!
- Becoming a Core Contributor – Don’t like the way NuPack works or want to dive in and help out, here’s how to join the team
- Discussion Forums – Come by and chat about NuPack, talk to the team and see what we’ve been chatting about, and propose new ideas and suggestions
- Issue Tracker – The team keeps on top of issues and features, why not vote some up or suggest new ones?
Other blog posts about the NuPack announcement:
While this project started as a pure Microsoft one, it quickly broke new ground in letting blokes like me in to contribute directly to the codebase. Let’s hope to see more Open Source projects from Microsoft like this in the future so that everyone can benefit and feel like they’re contributing to something value-add in the .NET universe.
This is just an overview of the features of NuPack. I’ll go into details about specific functions, building your own packages, running your own server, and exploring the source code tree in future posts.
Okay, no lasers in this post but it has almost everything else! Enjoy the new tool, go build some packages, and keep on challenging yourself!