Today will be remembered as the day that NuGet.org went down and broke quite some builds. While many people would love to see the NuGet team wearing a pink sombrero, there is something to say about wearing it yourself if you did not manage to workaround this. Let me explain… First of all, just as with the Azure downtime on a leap day, whenever you rely on an external system and make it mission critical, you should design for failure. You need to anticipate downtime. I’m sure the NuGet team does everything within its power to fix this and is going to inform us whenever they can, but give them some credit please: we’re all human beings making mistakes, that’s how we learn.

How do I know it’s not just me?

• Check twitter for the hashtag #nuget and scan for issues.
• Check http://status.nuget.org
• Check the NuGet room on Jabbr

Here’s what you can do

The best thing one can and should do, again, is to anticipate. Have a backup repository, or mirror packages on a MyGet.org feed. Looking at my twitter streams, it is striking to see how many did not think about it.

If you have your packages in source control, impact is limited to not being able to upgrade your packages or install new packages. If you don’t have your packages in your VCS, and you did not anticipate, you might get lucky enough and fix your builds by targeting the local NuGet cache.

Simply register the following path as a NuGet package source and target this one:

%Localappdata%\NuGet\Cache

Avoid spending your day fingers crossed!