NuGet Productivity Hack

This article explains how with a couple of quick hacks you can gain a little extra productivity when using NuGet.  The hack it's self is simple, Just add NuGet's local cache as a feed.  It turns out this can save you time, keep you team mates on side and even improve your presentations.

Originally I did this to help with development of API's that develop and use in house.  We were facing a problem with rapidly increasing version numbers when initially developing an API for the business logic of our product.  Each developer was working on one vertical slice of the product meaning that they may have to tweak the API if they found something that they hadn't considered in one of the layers of the application.  The simplest way to develop the package dependent on the API is to update it with NuGet. 

Our process for getting packages into the shared NuGet repository is simple.  We publish packages to NuGet after a build on our Continuous Integration server.  That way we know that each build has passed tests and that each package is as stable as it can be.  We follow Semantic Versioning and our rule is once it's in NuGet it's published.  So any change to the interface after that point means that the version number needs to change.

So in order to include a package into the dependent project without first pushing it through the NuGet process I needed to publish it locally.  I had to pick somewhere so I thought why not into the local cache. This way I don't need to keep tabs on somewhere else in the system and as long as the version of the package that I finally pushed to CI was the same as the last one I pushed locally or had a higher version number then NuGet would take care of making sure that what I was developing against was the same as everyone else. Unless of course it explicitly wasn't.

Great, with this I was able to develop an API, change it as often as I wanted while making sure it integrates smoothly with the dependent package and not ramp the version numbers up needlessly.  Awesome! that's some productivity bonuses right there.  No more waiting for the slow build server to build and publish the package.  No more annoying the rest of the team with increasing versions and breaking APIs.

But this is all expected, it's the desired outcome of the problem I had.  I got a pleasant surprise as I kept working.   With the local cache at the top of my NuGet repositories list it was loaded up first when I went to add a new package.  Because it's accessing the local disk, an SSD, it was almost instant to load the add packages dialogue.  I'm not sure if serving the package list is universally slow or if it's our internal infrastructure but I found that this saved me several seconds and a fair bit of frustration when going to add commonly used internal and external NuGet packages. This may not save too much time but it does save a little frustration waiting for the NuGet dialogue.

Bonus!

The other day while attending the local Newcastle Coders Group we had Internet access issues, rather par for the course at the University of Newcastle.  These issues inhibited the presenter from being able to add the packages he required in order to do his demonstrations.  This might normally have stalled the presentation.  Instead I was able to get him to hook up his local cache as a repository and continue with the presentation.

So there we have it.  Publish packages to a local NuGet feed and avoid annoying your team members.  Make that feed  your local cache to speed up your daily development in adding regularly used packages to projects.  Use the local feed to have access to regularly used packages when for some reason you have no internet access.