My First Experience with NuGet Package Creation

Frankly, it is about time I started distributing some of my projects through NuGet. In case you are a .NET developer and were living under a rock for the past year, NuGet is:

A Visual Studio extension that makes it easy to install and update third-party libraries and tools in Visual Studio.

If you used APT before, this is a similar concept in a different wrapper. Today, I decided to start with a project of mine - KinectContrib. Currently it offers a set of templates for Visual Studio 2010 that make Kinect development easier to some extent by providing the basic structures that handle various sensor data, like depth, video and skeleton.

With all the hype around NuGet (besides, the simplicity that comes with it), I decided that it was time to try and distribute KinectContrib Templates via the NuGet service. At first, I was really confused as to what approach I should take, because apparently NuGet was designed to mainly distribute assemblies and associated content. For example, it is really easy to bundle a DLL with additional metadata and content. No extensive documentation was written to document non-assembly distribution models. In my case I had 9 ZIP packages that need to be placed in the My Documents folder - none of those were directly related to a Visual Studio solution, where NuGet really shines.

A lot of documentation refers to the fact that I need to put those in the content folder, that is being specifically designated for elements that are not directly related to library parts. I did that, but then I decided to separate some parts of the project for easier file manipulations. I created a Kinect folder and dumped the ZIPs there. The content folder was used for a README file - something that is required (correct me if I am wrong) to make the post-installation scripts work. Not specifically the README file, but rather something in the content or lib folders.

One really nice thing about creating NuGet packages is the set of conventions that make it easy to organize package data in a single iteration. There are multiple ways that can be done - for example, I could use a text editor and build my own nuspec file (package metadata), or I could use the NuGet GUI tool, that allows drag-and-drop package manipulation. It is all really intuitive, without any cryptic commands or parameters - the command line side of the tool provides enough self-help resources without the need to look up content in the official documentation.

As I noted before, I needed to manipulate the contents of the installed package once the installation is complete. Surprisingly, I am able to use PowerShell out-of-the-box. I needed to move a folder from its stock location to the Visual Studio project templates location. I ended up writing this as Install.ps1:

$localDir = [Environment]::GetFolderPath("MyDocuments");
$localDir += "\Visual Studio 2010\Templates\ProjectTemplates\";

Move-Item packages\KinectContribTemplates.2.0.0\Kinect $localDir

Once the package is downloaded and installed from NuGet, Install.ps1 is automatically fired, moving the required components (or whatever the script does, in other cases). I had to do some script debugging too, since PowerShell is something I am still learning, and again - the NuGet toolset comes really handy when it comes to showing the developer what's going on behind the scenes. All that needs to be done is open the Package Manager Console and select the repository where the package is located. Then, both NuGet and PowerShell will display the logs inside that panel:

Speaking about repositories, it was also extremely easy to test the package locally. The repositories that are used for package aggregation can be both remote (e.g. the NuGet.org official repository) or local (please read this post by Scott Hanselman).

From start to finish, it took me 20 minutes at most, including the time taken to get some extremely basic PowerShell skills. I published the package on NuGet.org (available here) and I am ready to go. Overall, I am impressed by how such a complex system can provide such a simplistic front-end. Kudos to the NuGet team!

Some helpful resources to help get you started, if you are interested:

• Introducing NuGet Package Manager
• NuGet Official Documentation
• You Really Should Be Using NuGet
• Writing a NuGet Package That Adds A Command To The PowerShell Console

Also, trust me - you want to know your way around PowerShell when working with NuGet packaging. So here goes:

• Scripting with Windows PowerShell
• Getting Started with Windows PowerShell
• Everything PowerShell-related

PS: Article summary image credit goes to Phil Haack.