Between nuget.org and private package galleries that your organization might establish, you can find tens of thousands of highly useful packages to use in your apps and services. But regardless of the source, consuming a package follows the same general workflow:
* *Except with
nuget install from the command-line, in which case it's necessary to edit the configuration files by hand. See the install command reference. *
NuGet remembers the identity and version number of each installed package, recording it in either
project.json in your project root, depending on project type. With NuGet 4.0+ and .NET Core projects, dependencies are instead stored in the project file directly. See Package References in Project Files. In any case, you can look in the appropriate file at any time to see the full list of dependencies for your project.
When installing packages, NuGet typically checks if the package is already available from its cache. You can manually clear this cache from the command line, as described on Managing the NuGet cache.
When adding project code to a source repository, you typically don't include NuGet packages. Those who later clone the repository, which includes build agents on systems like Visual Studio Team Services, must restore the necessary packages prior to running a build:
Package Restore uses the information in
project.json to reinstall all dependencies. Note that there are differences in the process between NuGet 2.x and 3.x+, which are described in Dependency Resolution.
Occasionally it's necessary to reinstall packages that are already included in a project, which may also reinstall dependencies. This is easy to do using the
reinstall command via the NuGet Package Manager Console. For details, see Reinstalling and Updating Packages.
Finally, NuGet's behavior is driven by
nuget.config configuration files. Multiple files can be used to centralize certain settings at different levels, as explained in Configuring NuGet Behavior.
Enjoy your productive coding with NuGet packages!