0

I am a dinosaur developer, so NuGet is relatively new to me, I am used to manage third parties open source libraries having a single project with the code or the binaries, that I will keep updated when necessary and this project publishes the dll(s) on a common folder from where I reference the libraries in all my projects. This makes easy to maintain the third party libraries and in my projects I just need to rebuild when I update the library and all goes OK. Now many open source projects publish their libraries on NuGet and it is easy to reference them in the projects, but I dread the fact that I have to download a copy of the library for each project in which I use it, this, in my opinion is something that can lead to chaos. Especially if I have 2 projects that build dlls that end up using 2 different versions of the same packages and are used both in an application with problems and conflicts. So my question to those who use NuGet from a longer time is: Can I proceed with NuGet packages as with other libraries and create a project that references them, use it to publish the dlls in a single folder and then reference the dlls of the packages from my dlls and applications on the published folder.

I hope I've been clear. Thanks for any thoughts you can share on this topic Sabrina

Sabrina_cs
  • 421
  • 3
  • 18
  • I still don't know why would you. You don't need to update packages if you don't want to. Updating packages doesn't usually break things, unless the package is done badly. Might be more trouble than worth trying to misuse NuGet – Sami Kuhmonen Nov 09 '16 at 09:56
  • If you are using VS2015, you can consolidate NuGet package versions in the UI, otherwise there is a Package Manager Console command called `Sync-Package` that will also do it - however I have never used it before. – Michael Coxon Nov 09 '16 at 10:02

1 Answers1

1

Having all your 3rd party libraries for all your projects in a single folder can lead to dll versions hell. If you update a single dll which contains breaking changes and which is referenced by other projects, then you will have fix/rebuild all projects that references it.

To resolve the issue with downloading the same packages for every project you can create a local repository and configure Visual Studio to use your local repository. So if your local repository contains a single version of log4net, you'll be able to use only that specific version. Even more you can configure repository to use a shared folder, in this case all developers and even your build server will be able to use that repository.

There are a lot advantages of using NuGet, such as saving a lot of space on your hard disks and others. For example I created NuGet packages for our internal framework, so all our projects just reference those packages, rather than each project has its own version in its bin folder.

Community
  • 1
  • 1
Andrei Mihalciuc
  • 2,148
  • 16
  • 14
  • I've read the article you linked on local repositories and I found it very interesting, it is just a little "ancient" but I've found what it uses. Still, maybe I'm a little senile, but how will I download the packages on my local repository, is it something that has to be done from NuGet or something done from visual studio? I feel old and dumb... sorry – Sabrina_cs Nov 09 '16 at 14:37
  • 1
    I've updated my answer with a link on how to download packages and configure Visual Studio – Andrei Mihalciuc Nov 09 '16 at 14:47
  • That was most useful! I've found some solutions in NuGet.org Like the ASP application and the NuGet.Server and another article to use TFS but even if feasible, they are too complicated for my personal use. Thanks again for the help – Sabrina_cs Nov 09 '16 at 15:04