NuGet Is Down. Now What?

Author, Damir Arh

NuGet - Activity


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.


Nuget Is Down - Twitter Feed

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 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

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 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:

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.

The following two tabs change content below.

Damir Arh

Damir Arh has been involved with Microsoft technologies, since he has been a student. He has many years of experience with development and maintenance of complex enterprise software in the field of document management, insurance, and process management. Recently he has shown increased interest in the heterogeneous ecosystem of mobile devices and cross-platform development. Damir is always looking for tools and processes to make development easier and more manageable, making him a big proponent of test driven development, continuous integration and continuous deployment. He coauthored a book on NuGet – the package manager for .NET framework. He likes to share his knowledge with others by answering questions on Stack Overflow, blogging and regularly speaking at local user groups and conferences. For his contributions to the community he is an awarded Microsoft MVP since 2012.

Related posts

One Comment;