This entry is also available in Dutch.
The ever so popular Visual Studio extension named NuGet enables the developer to easily install packages from within the development environment. NuGet packages contain populair and less known libraries, like log4net, jQuery and Entity Framework.
The NuGet-extension for Visual Studio is installed with a few clicks, after which packages can be added to an already loaded project. Apart from the graphical user interface that enables the searching, installing and updating of packages, a PowerShell console for the package manager is also added to the menu.
From this console the command Install-Package $PackageName installs the mentioned package (using tab completion!), while in doing so also the correct references, configuration and possibly even code files are added to the project. In the also created (or updated) file packages.config in the root of the project the used packages are registered, together with their active version. While the first successful Install-Package will create the packages.config-file, the successive Uninstall-Package for the last package will remove the file.
When a solution contains multiple projects, the NuGet console will operate on the project that is set as Startup Project in Visual Studio. To add packages to a different project in the same solution, you can expand the Install-Package command with the parameter -ProjectName $ProjectName. This works for all package management commands from the NuGet console, including removing and updating packages. The latter happens using the command Update-Package.
By default packages are downloaded to the packages directory, in the root of the project they are applied to. If you are working on multiple project that each contain their own packages, those files can rapidly consume an unnecessary large amount of disk space. To prevent this, a simple solution was introduced with NuGet 2.1.
Shared packages directory
NuGet will try to find a cached download of a package. It does so by first scanning the packages directory in the project root, and if that cannot be found it will start searching for the file nuget.config, from the project root up until the root of the active disk. In this file you can configure the NuGet settings for all projects that are in any subdirectory of the directory containing the configuration file.
Considering my disk layout, I have placed the file at D:\Dev\Visual Studio\Projects\nuget.config. It contains the following lines:
<configuration> <config> <add key="repositoryPath" value="D:\Software\Libraries\NuGet\packages\" /> </config> </configuration>
This way all packages that are added to projects under D:\Dev\Visual Studio\Projects\ will be stored in the directory D:\Software\Libraries\NuGet\packages\. This will only work though for projects that don’t already have a packages-directory in their root. If that folder does exist, NuGet will use it as package source and cache for that project.
Automatically downloading packages
Apart from sharing package sources, NuGet can do more magic with packages. They can be automatically downloaded, which can prove itself useful when projects are shared between different machines or have to be built automatically.
If you enable package restore, NuGet will check whether all packages mentioned in the packages.config are present. When they aren’t, they will be automatically downloaded.