Using NuGet package manager brings many advantages to your development process, but also one very unfortunate side effect: additional dependency on an external service – official NuGet package source. Its uptime isn’t bad at all, but looking at the NuGet Twitter feed, we can find several notification about service interruptions in recent months.
Although the issues usually get resolved quite quickly, it’s good to know how they can affect you. In my opinion the most critical process that can be affected by NuGet.org downtime, is the build (continuous integration, delivery and deployment). The only required NuGet service in this process is package restore. When is it required and what are the alternatives, when this service is down?
Package restore delivers (or restores, as the name says) NuGet packages, required by a project, to the local working directory, because they aren’t stored in source control. It is usually the first step in build after the code in the working directory is updated from source control; before the compilation happens. For most of the builds, the package restore step doesn’t contact the NuGet feed at all, because all packages in the working directory are already up-to-date. There’re only two exceptions, when the packages actually need to be restored:
- When a new package or a new version of a package is newly required since the last build (you can’t really affect this at the build process level).
- When the working directory is being recreated (usually it is possible to configure build servers when (if at all) a different working directory is used for a build).
If NuGet.org is down when this happens, the build will fail. The only way to prevent this is to get the packages from elsewhere, usually from a local cache.
NuGet and Local Cache
It’s a little known fact, that NuGet has a built-in local cache on the machine. It is located inside the user’s AppData directory (C:\Users\Username\AppData\Local\NuGet\Cache), meaning that builds on the same machine run under the same identity will share the cache; therefore if a package has already been used for any build, it won’t be downloaded again.
Unless you have a very good reason against it, all your builds on one machine should run under the same account. Of course, you will still distribute the builds across multiple machines because of performance or high availability.
Share Package Cache Using Nexus
To share the package cache across more than one machine, you will need to setup a local proxy feed. There are a couple of solutions available for that, Sonatype Nexus being one of them. You can find all the information on how to set it up in my previous articles:
- In Getting Started with Nexus, I describe how to configure a proxy repository in Nexus.
- In Use a Repository Group to Consolidate Multiple Repositories, I include instructions on configuring NuGet to use a repository from Nexus instead of the official NuGet feed.
If this proxy repository is used by all developers as well as by the build servers, all packages required by the build should already be cached; Nexus did that when the developer downloaded the package to include it in the project in first place.
Create a Backup Plan
If you’re following the official NuGet blog, you can see that monitoring, quick response to failures and high availability are among the top goals for the next version of NuGet. Still, if your build servers are mission critical to your business, it makes sense to have your own backup plan. It will keep you up and running even when you lose internet connectivity.
Latest posts by Damir Arh (see all)
- NuGet Is Down. Now What? - December 15, 2014
- NuGet and Nexus: Use a Repository Group to Consolidate Multiple Repositories - November 11, 2014
- Nexus and NuGet: Create a Hosted Repository - October 17, 2014
- Get Started with Nexus and NuGet - October 6, 2014
- Nexus for .NET Developers: New Series - September 9, 2014