Question

I know Package Manager like NuGet help us when we want to use third party components.

From Nuget Codeplex Page:

NuGet is a free, open source developer focused package management
system for the .NET platform intent on simplifying the process of
incorporating third party libraries into a .NET application during
development.

There are a large number of useful 3rd party open source libraries out
there for the .NET platform, but for those not familiar with the OSS
ecosystem, it can be a pain to pull these libraries into a project.

Let’s take ELMAH as an example. It’s a fine error logging utility
which has no dependencies on other libraries, but is still a challenge
to integrate into a project. These are the steps it takes:

Find ELMAH
Download the correct zip package.
“Unblock” the package.
Verify its hash against the one provided by the hosting environment.
Unzip the package contents into a specific location in the solution.
Add an assembly reference to the assembly.
Update web.config with the correct settings which a developer needs to search for. 

And this is for a library that has no dependencies. Imagine doing this
for NHibernate.Linq which has multiple dependencies each needing
similar steps. We can do much better!

NuGet automates all these common and tedious tasks for a package as
well as its dependencies. It removes nearly all of the challenges of
incorporating a third party open source library into a project’s
source tree

these steps are simple tasks that we do when we want to setup a project. its only for automation of adding 3rd party components and decrees chance of Error in configuration files? or it has much more responsibilities !?

Answer 1

It’s value is hidden in the open: a package manager such as NuGet helps you dealing with software dependencies using automation. Many make the assumption that it’s only meant for open source or third party components, but you could equally as well use it for your own internal packages.

The great thing about NuGet is (to name a few benefits):

• NuGet encourages reuse of components because you implicitly rely on actual “releases” (even if pre-release), instead of branching sources
• you can get rid of binaries bloating your VCS repositories (package restore feature)
• it forces package creators to think about the way the package will be consumed and leaves them dealing with configuration of the component during package installation (who knows best how to configure the package than the package creators?). Think about ELMAH as an example.
• automating package creation and publication on a package repository effectively is a form of continuous delivery (for software components). OctopusDeploy even takes it a step further and enables packaging entire Web sites ready for deployment.
• NuGet encourages and sometimes enforces you to follow some ALM best practices. E.g. a package has a version, so you have to think about your versioning strategy (e.g. SemVer.org)
• NuGet integrates with SymbolSource.org (which also has a Community edition to set up your own): this allows one to easily debug released packages without having to ship this info all the time
• having one or more package repositories makes it easy for the organization to maintain a dependency matrix, or even build an inventory of OSS licenses that are in use by several projects
• NuGet notifies you about available package updates
• Creating packages makes people think about component architecture (all dependencies should be packaged as well)
• Dependencies of a package are automatically resolved (so you can’t forget any)
• NuGet is smart enough to add assembly binding redirects when required

The above list is non-exhaustive, but I hope I covered the key benefits in this answer. I’m sure there are more.

Cheers,
Xavier