This document discusses the old MSBuild-integrated package restore approach. With NuGet 2.7, a new Automatic Package Restore approach has been introduced. For more information about that approach as well as a new NuGet.exe Restore Command, see the Package Restore reference document.
The original NuGet workflow has been to commit the Packages folder into source control. The
reasoning is that it matches what developers typically do when they don't have NuGet: they create a
ExternalDependencies folder, dump binaries into there and commit them to source control
to allow others to build.
While this has worked fine for some users, we have also heard from many that committing packages into source control is not what they want to do. When using a DVCS like Mercurial or Git, committing binaries can grow the repository size like crazy over time, making cloning more and more painful. In fact, this has been one of the top requests on NuGet our issue tracker.
The good news is that NuGet now offers a workflow which goes a long way to solving this problem, and is really easy to set up. Here is the way to do it:
Beginning with NuGet 2.0, restoring packages during build requires explicit consent from the user. This must be done on each machine that builds the project.
In Visual Studio, enable "Allow NuGet to download missing packages during build". This setting lives under Options -> Package Manager -> General.
To enable package restore for build servers without Visual Studio installed, you can also set the
EnableNuGetPackageRestore to "true".
Let’s assume that you have a solution that is either already using NuGet, or planning to use it, and that you want to set up the no-commit workflow.
Right click on the Solution node in Solution Explorer and select Enable NuGet Package Restore.
That's it! You're all set.
So what exactly did that do? It added a solution folder named .nuget containing NuGet.exe and a NuGet.targets MsBuild file. More specifically, it downloaded and extracted two NuGet packages: NuGet.Commandline for NuGet.exe and NuGet.Build for NuGet.targets. It also changed every project in the solution to import the NuGet.targets MsBuild task.
Finally, it added a NuGet.config file with the following XML:
<configuration> <solution> <add key="disableSourceControlIntegration" value="true" /> </solution> </configuration>
The disableSourceControlIntegration setting instructs version control systems like TFS to not add the NuGet packages folder to the pending check-ins list.
With this in place, any time a project is compiled, the build task will look at each project's packages.config file and for each package listed, ensure that the corresponding package exists within the packages folder. For any missing package, the build task will download and unpack the package.
In this scenario, NuGet will grab the exact version when restoring a package. It will not perform any upgrades.
Be sure to check in your repositories.config file. Some version control systems,
such as Subversion (a.k.a. SVN), may require additional configuration to allow you to selectively ignore an arbitrary set of files in a path, but include a specific file, such as your repositories.config in that path.
For SVN specifically, you may use SVN:IGNORE to prevent paths with certain patterns from being committed (and making a mess in your pending changes views). By adding the following patterns as an SVN:IGNORE to your "packages" directory, the repositories.config will be committed, but nuget package directories will be ignored.
On mono you can run
xbuild on the project file or on your solution and it should successfully
restore packages for any project that has package restore enabled.