Warning - the following is an opinionated piece and based on my experience. It doesn't reflect that of any of my employers or of any sane human beings
In case you've been living under a rock for the last few months you should have heard about NuGet, and if you have been here's the abridged version.
NuGet is a package manager for .NET projects. Basically think Ruby Gems, NPM for Node.js, etc and you'll come up with NuGet for .NET.
NuGet isn't the first attempt at a unified package management system, OpenWrap was here first, but it didn't seem to have the reach that NuGet seems to have (yes this could be because you've got the official Microsoft stamp of awesome, lots more Microsoft shills blogging about it, etc), but that shouldn't be important, what's more important is there is actually a package management story for .NET now.
How does NuGet work though?
Well NuGet is made up of two parts, first there is the NuGet Gallery which packages are uploaded, packages can be downloaded, etc. This is data provided to connecting clients using OData (which allows cool things like querying with LINQPad). You can also create your own NuGet server using the NuGet.Server package.
Consuming NuGet can be done a couple of ways. As mentioned above you can use an OData reader such as LINQPad. You can write your own consumer that uses the NuGet.Core package (which I covered in detail in this post) or you can use the Visual Studio 2010 tool.
The Visual Studio tool also include a set of Powershell scripts which mean that you can call out to NuGet from Powershell, although I'm not entirely sure how well it'd work outside of Visual Studio as it does seem to use some of the VS API to add references to a project. But the Powershell tools are cool, they allow you to do things like this.
What makes up a NuGet package
A NuGet package, or nupkg file, it really just a ZIP file with a manifest within it. The nuspec format is documented and can easily be implemented. The way the files are treated has also been documented and most of it is based off of conventions. Really the main two you need to know are:
- /lib files go into the project references
- /Content files go into the root of the project (and folder nesting is allowed)
There's also a Package Explorer tool available if you want to dig around the internals of existing packages.
Should you care?
I think that NuGet is something that is very vital to the .NET ecosystem. The lack of a unified package management system has been the bane of .NET development for a long time. Yes NuGet wasn't the first, but does that really matter. I don't care for the arguments that were waged when NuGet first came out. Accept that it's here to stay and move on.
And with that said I'm of the opinion that if it's not on NuGet then it doesn't exist. Harsh as this may seem but I've got better things to do than:
- Find the latest stable build
- Monitor a project for new versions
- Update my version when new releases are out
Ask any Rubiest if they'd use something that wasn't a gem and you'll pretty much always receive a no.
Is NuGet just for Open Source?
This was a question asked at a developer event recently, and although it seems that most of the projects which are on NuGet are OSS I don't see why NuGet would be confined to OSS.
I don't think that you could really do anything truly commercial from the official NuGet feed, but I can't see why you couldn't have a trial version of a library on there and as part of the install process' T&C's state that it's got restrictions.
NuGet and Mono
Something that was a topic of discussion last night with Demis was "Does NuGet work on Mono?" and from the quick searching I did it would seem that there isn't a Mono version of the "Add Library Reference" dialog that the Visual Studio tools provide. From what I read there is some limitations to running NuGet on Mono (and I'm referring to the Mono CLR) due to some CLR 4 features that NuGet uses which aren't available on Mono yet.
Demis argued that if Microsoft was really serious about NuGet being a way to deliver open source projects to developers then they should be ensuring that it has Mono tooling.
I beg to differ on this point. Microsoft have done (mostly) the right things so far, the source is available, there are contribution guidelines if you want to fix issues and there is documentation on the package format. This is about as open source as you're going to find from Microsoft these days and it's a heck of a lot better than the Microsoft of old, but as for actually building the tools for MonoDevelop, I think that's something they should stay away from.
If Microsoft was to add the support to MonoDevelop then it could be seen very much as an overbearing effort to push the platform (not that it's not being pushed hard already :P).