At my work we have our own NuGet feeds. And we tell our developers to disable the official NuGet feed. Why you may ask?
Let me explain with an example:
A new project is started, developer X decides, let’s use Ninject. So he downloads Ninject from the official feed, which is now at 3.0.1.something. He uses it. After a while a request comes in, it’s discussed, and internally we already developed a package to aid said developer with those tasks. However that package has a specific dependency on Ninject 2.something.something.something. Now what? The developer will have the hassle to downgrade his Ninject package, and more importantly, he might need to rewrite code because the API of Ninject 2 and 3 differ.
Hence why we would like to constrain the packages used. We set up our own feed, and if needed we copy packages from the original feed to ours.
So this is the setup: 2 feeds in the package manager, one is the official one, that’s unchecked, and ours:
Next up: a developer starts a new Visual Studio solution. He doesn’t want to commit the packages he uses to source control, so he decides to go with Nuget Package restore.
So what’s going on? Let’s ask Fiddler:
It’s looking for the NuGet.Build package. Fine. I downloaded that one, again, we don’t to use the official feed at all.
So I put that package in our NuGet feed, and tried to enable package restore again:
What? I make a copy of a package and now it gives me an error?
Let’s look again with Fiddler:
Aha, it finds the package, but appearently it’s using a hard coded path to find the package on the server. Since we don’t have the same URL structure it fails.
So it seems that I have to stop my investigation here. Since we cannot (and do not want to) move our NuGet url we decided that we just pull NuGet.Build and NuGet.CommandLine from the official NuGet server.
We deleted it from our server.
Update: This is also happening because we use NuGet.Server. This one doesn’t host the stuff on the same location and the NuGet feed is hardcoded in the NuGet dll. But then again, NuGet makes an assumption. And that’s bad!