42

I don't get it - can someone please explain to me why I should use NuGet rather than installing a bunch of libraries via a setup.exe or MSI? What advantage is there?

For example is it better to install Entity Framework 4.3 via NuGet rather than downloading the setup? Also, if I install entity framework via NuGet then is it available to any new solutions or projects that I create (bit confused here).

Basically what does NuGet do that a normal install doesn't do (or vice versa!)

Matthew Murdoch
  • 30,874
  • 30
  • 96
  • 127
Calanus
  • 25,619
  • 25
  • 85
  • 120

4 Answers4

34

Besides making it simple to add a package to your project, I think NuGet's biggest advantage is dependency management.

NuGet allows project owners to package their libraries as packages. Before, if they depended on other libraries like log4net, they would include those assemblies in their setup/zip file and upload to their web site.

With NuGet, they simply add a reference to these external packages in the .nuspec file. When NuGet installs the package, it will see that there are dependencies and will automatically download and install those packages as well. It also supports conflict management so that if 2 packages depends on different versions, it will figure out the correct one to install.

I think the best way to determine if NuGet will work for you is to actually try using it. I'm sure that once you do, you'll realize that it has many benefits.

Kiliman
  • 18,460
  • 3
  • 39
  • 38
  • `will automatically download and install those packages as well`, what if the internet is not available at the site? – bjan Mar 13 '16 at 13:36
  • The "will automatically download" was in reference to dependencies. The initial package install is initiated by the user. As for no Internet access, you can download all the packages you need from another location, and then copy those to the target machine. Now you can add the local folder to your NuGet package repositories and installs will pull from there instead of nuget.org. – Kiliman Mar 13 '16 at 13:51
  • I recently faced a problem which got me confused. I developed a solution having multiple helping (my) libraries, different libraries were using different packages added via nuget. I referenced one of the library(single dll file) into another solution and on Build, VS2010 complained about the refernced library rather than the missing package. Is there any way i could know which package is missing/required in this particular case. – bjan Mar 13 '16 at 14:26
20

Nuget provides several additional benefits:

  • it automatically configures your projects by adding references to the necessary assemblies, creating and adding project files (e.g. configuration), etc.
  • it provides package updates
  • it does all of this very conveniently
Jon
  • 428,835
  • 81
  • 738
  • 806
16

What advantage is there?

Nuget simplifies third libraries incorporation : With a single command line (Install-Package EntityFramework) you make your package available for your project. Instead of googling-find the package-download-setup-reference the package in your project...

Auto-Update is not mandatory, Nuget configuration file let you specify the version, or the range of version, that your application is compatible with.

Also, if I install entity framework via Nuget then is it available to any new solutions or projects that I create

Once you installed a package, dlls are copied in a directory at solution level, you can then reference them from there in others projects of your solution.

For each new solutions, re-installing packages is a better solution. As it is very easy with nuget, it won't be a problem.

user484189
  • 191
  • 5
  • +1 for saying that packages are installed at the solution level. It is not uncommon to have multiple web apps (projects) in a single solution and nuget has that covered. – styfle Sep 25 '13 at 16:42
  • I developed a solution having multiple helping libraries, different libraries were using different packages added via nuget. I referenced one of the library(single dll file) into another solution and on Build, VS2010 complained about the refernced library rather than the missing package. – bjan Mar 13 '16 at 14:11
8

Nuget contributes to creating a DLL hell and makes the solution go out of control very quickly, especially when different versions of so called "packages" come into play. Apart from assembly versioning, there are now nuget package versions. Nuget is just adding another wrapper over DLLs and does nothing that would make developers' life easier.

Valery Gavrilov
  • 184
  • 1
  • 3
  • 2
    The question was - why should one be using Nuget. My answer is - to make their life harder and enhance the dll hell issues. How does this not provide an answer? – Valery Gavrilov Oct 22 '15 at 22:12
  • 1
    Thank you for providing a balancing voice. I wish the OP would've asked for pros AND cons. – Doug S Jun 13 '16 at 06:08
  • 3
    So if someone asked "Why am I so beautiful?" on stack overflow the only answers that should appear are explanations as to how beautiful that person is? Even though the question is asking for the positive it is more constructive to consider the negative as well. – bryjohns Oct 18 '16 at 06:43
  • Dll hell may be misconstrued here as having a hard time to manage dlls for developers. 2 components of dll hell was to either not have the correct version of the library or not to have the copy at all. Nuget solves both problems - your dll is packaged as a group of libraries and distributed like that, with the specific versions of each dll. – RooiWillie Jul 06 '23 at 08:49