Updated all my Silverlight 5 posts Sharing Code Between Platforms

NuGet: little known features

Published on Thursday, December 8, 2011 10:49:00 AM UTC in Programming & Tools

To me personally, NuGet is one of the greatest additions to a .NET developer's life during the last years. It's simple to use, makes your life easier, and simply works. I like how quickly it is adopted by customers, friends and public projects, and extensively used everywhere. However, I often see that people do not know about all the available features and sometimes even create custom solutions to problems that are already solved by built-in options. In this post, I randomly pick three features you should know about when you're working with NuGet, and create your own packages.

Package Restore

Edit 2011-12-13: NuGet 1.6 incorporates this into the core functionality (no Power Tools needed anymore). I updated the below paragraph to reflect that.

Developers often commit external libraries to their source control system; this is not something new or special to NuGet. One of the problems with this however is that the size of your repository can grow extensively over time, in particular with frequently updated dependencies and/or when a dependency contains assemblies for multiple target platforms (that you maybe don't even use). Especially with distributed source control systems this can become really painful.

To overcome this problem, NuGet offers a feature named "Package Restore". The way this works is that locally missing packages (i.e. the first time after you've cloned a repository) are installed automatically when you build the project in question. To make this work, behind the scenes both NuGet.exe and a targets file are pulled into your solution, and then the project files are altered to make use of this target. You don't need to worry about these technical details if you don't want to - all you have to know is that this eliminates the need to add any external NuGet dependencies to your source control. You only need to commit the added NuGet.exe and targets file.

To make sure everything is identical to your original setup, the restore feature will grab the exact version of dependent packages. Detailed instructions and information can be found on the NuGet documentation page here:

http://docs.nuget.org/docs/workflows/using-nuget-without-committing-packages

Create Your Own Feeds

NuGet is a great tool, but only for publicly available packages, right? Wrong! You can benefit from NuGet's features for your internal components and packages too, without worrying about publicly exposing your IP.

NuGet works with feeds to obtain packages, and the official public feed is only one of the possible sources. It's extremely easy to set up your own feeds; in the simplest case you only add a folder with additional packages to the package manager settings in Visual Studio. Another alternative is to host a feed in IIS, and again this is very simple to set up because - did you guess it? - there's a NuGet package for that (NuGet.Server). With these features, you can use NuGet's power for your internal code base and developer team too. Again, detailed instructions are available on the NuGet documentation site:

http://docs.nuget.org/docs/creating-packages/hosting-your-own-nuget-feeds

Simplify and Automate Package Creation

When you create your own packages, things can become a bit tedious. Every time you prepare a normal release, you have to manually edit the nuspec file and recreate the corresponding package(s). Naturally people are interested in making this more comfortable and automating this process.

I'm guilty of writing custom solutions for this myself: using custom targets to integrate this into the build process, parse the nuspec Xml and replace key data like the version information dynamically with what you also dynamically extracted from the involved assemblies - it really can become quite complex. The thing is, you don't need to do anything like that, because there's a built-in solution to it.

Did you know that you can create packages from a project file? You simply point NuGet to it, and it does all the work for you. The great thing about this is that it can be customized to fit your needs. For example, based on conventions you can simply put a nuspec file next to your project file, and it will be picked up during the packaging automatically. In that file you can use placeholders like $version$ to dynamically set the version information to that of the output assembly - which means no more manual editing of nuspec files, and with a single command line this can easily be integrated e.g. as post build step. Additional options allow you to specify the configuration that should be used to create the package (i.e. debug/release), and more. Details about this can again be found in NuGet's documentation:

http://docs.nuget.org/docs/creating-packages/creating-and-publishing-a-package

Conclusion

It's really good to see that the development of NuGet itself is driven by community requests and needs, and that a lot of the issues and scenarios are addressed quickly. You and your team can benefit from this, and by making use of these "hidden" features improve your development experience even more.

Let me know if you have any questions, feedback or additional points to add.

Tags: NuGet