Package Managers are awesome … when they work ! Lately I’ve been having a lot of trouble running NuGet package restore commands on my dev machine. Its all my own doing but I thought I’d share the pain points with you and 5 simple steps to to follow whenever you encounter the error that will get you back up and running…
Step 1 – (seriously) close visual studio ,reboot your machine and try again
Step 2 – disable any HTTP debugging proxies on your machine
If you are running a local proxy debugging tool such as Fiddler or OWASP Zed Attack Proxy you’ve broken NuGet ! You’ll need to turn them off (open fiddler=> fiddler option => connection => uncheck “act as system proxy on startup”) and ensure that the environment variable HTTP_PROXY is removed from your system settings.
Step 3 – (seriously) close visual studio again , reboot your machine and try again
Step 4 – clear the package cache(s) on your machine
NuGet has deep pockets and lots of them !
- Delete the contents of the folder
- Delete the contents of the “packages” folder that sits alongside your visual studio .sln file
Step 5 – If you are using a custom package sources delete and recreate it
We run an internal NuGet server in the office, the trouble is I work remotely from the other side of the world so I need to connect over a VPN to access the server, this is way too slow for me so I sync up the contents of a local folder on my pc with the NuGet packages from the office and point to this using a custom package source that points to the folder.
Occasionally NuGet has trouble dealing with this and I need to delete the Package source and recreate it…