What are the advantages of using a private NuGet server?

Question

What are the advantages to using a private NuGet server as opposed to having shared library projects which are then included in every solution?

We have several libraries which are shared across our code-base which currently I've included using a relative path to the project within each solution.

The current problem I can see with a shared project, is that TFS uses folders for its branching strategy and that breaks the project's relative path links in each solution. So a NuGet server would get round this issue.

Answer 1

I would say the number one advantage over shared projects is versioning and dependency management. With shared projects and code files, you always have the most recent version, which may or may not be desirable. Another advantage would be that if you had multiple teams that are responsible for library deployment within your organization, they could use an agile approach to deploy early and often to the private feed and you as the consumer would get to select which version is right for you to reference.

Of course, for small teams, you may want to develop with shared files. At my company, we were able to function this way until we discovered that we were sharing slightly different code over several customers' projects, and we needed a way to host and manage our own private libraries. When we discovered NuGet, it didn't quite solve these problems in the way we wanted so we built ProGet to host our own private feeds.

If you're thinking of adopting the NuGet approach for your organization, take a look at this article written by a colleague of mine for some of the pros and cons of adoption. Even if you don't qualify as an enterprise, most of the points are still relevant.