Enabling Using NuGet Without Checking In Packages Folder

This spec covers how NuGet plans to enable a more “Maven” style workflow for those who do not wish to check-in their packages folder. While the current recommended approach is to check-in the packages folder to ensure a repeatable build without dependencies on any external systems, the NuGet team recognizes the need to support an alternative model without negatively affecting the original model.

We’ll be implementing this workflow in a series of iteration releases starting with the following feature in NuGet 1.4. In the meanwhile, do read David Ebbo’s blog post on how to do this today using NuGet.exe.

Restore Packages from packages.config

Work Item: 165

Discussion Thread

Problem Statement

When installing packages into a project, NuGet creates a packages.config file within the project which serves as a record of exactly what packages are installed in the project. At the same time, a folder for the package is created within the solution level packages folder containing the package and its contents. Currently, it’s expected that the packages folder is checked into source control. The reason for this is that certain files from the package, such as assemblies, are referenced from the packages folder. That way, a package that is installed into multiple projects does not copy the assembly into each project. Instead, all the projects reference the same assembly in one location.

If another user gets latest from source control, and the packages folder is missing, the project would fail to build because the referenced assembly would be missing.

Feature Solution

This new feature will make it so that if the packages folder (or any package folder within the packages folder) is missing,  the packages folder (or missing package folder) will automatically be restored when compiling the application. This ensures that the application will compile even though the packages folder was missing at the time.


Solution level menu to Convert Solution to Restore Packages.There is no going back. once you run it, the menu option goes away.


  • Works outside of Visual Studio such as when using MSBuild.exe to compile the solution within a CI server environment.
  • Works in an integrated fashion within Visual Studio. When you compile the project, missing packages are restored.


  • Feature is off by default. (Based on feedback, seems like it’s safest to leave this off. People using current model want the build to be broken if you forget to check in packages)
  • Enabling the feature turns off the TFS stuff.
  • Adding new projects: We need to hook it and do the right thing.
  • .nuget folder parallel to the packages folder.
    • Contents of this folder are added to a Solution folder: .nuget
    • Contents: NuGet.exe, NuGet.Settings.targets, NuGet.targets
  • When restore is enabled, we should restore packages when we detect installed packages are missing. Such as when they launch the dialog or try to use the package manager console.
  • Privacy issues?


1. Install Package First Time
    a) Adds Nuget.config and NuGet Build Target (within NuGet.exe) to Solution level (within Solution Folder)
    b) Adds custom build task

2. Build from VS or msbuild.exe
    a) BeforeBuildTarget: Checks packages.config for the project.
    b) Attempts a restore if any packages are missing.


  • This doesn't apply to Websites. doesn't break WebMatrix.
  • Restoring Solution Only Packages (packages not installed within a project), is not supported in this iteration.


  • Need to validate that this works with a CI machine running under SYSTEM or similar account. Look at how typical CI machines are setup.

Last edited Sep 26, 2011 at 9:27 PM by Haacked, version 8


sydneyos Jun 26, 2012 at 7:18 PM 
Great idea, but it hosed my solution - can't build anymore. Is there no way to manually roll this back?

michielvoo May 25, 2012 at 11:36 AM 
Why is the solution folder added?

dominicb123 Oct 18, 2011 at 3:27 AM 
I'll add a vote for the "Clean" option to clear down packages first. This will be useful in CI scenarios where packages may not be versioned for various reasons.

BenPhegan Oct 4, 2011 at 11:39 AM 
Based on our experience so far, adding nuget.exe to each solution could become a real pain, so perhaps adding nuget.exe to source control should be optional? As long as the msbuild targets are able to fall back to a system available nuget.exe, this would reduce a lot of overhead when a new version of nuget.exe comes out and you want developers to take advantage of it (again in a corporate setting). With 500+ solutions, it could be quite a chore to update.... :)

thargy Aug 19, 2011 at 4:00 PM 
I have to say that this is fundamentally the main issue stopping a lot of companies adopting Nuget. We've adopted it, but the Hobson's choice of checking in packages vs. an inability to easily restore packages combined with the inability to easily build multiple NuGets when a core dependency is updated has really killed the experience.

NathanaelJones Aug 12, 2011 at 3:55 PM 
I have to disagree - repopulating the packages folder should be automatic. I was hoping NuGet was going to finally be something for .NET that "Just Worked". But despite the fact every other package manager (that I've used) automatically re-downloads missing dependencies, NuGet won't? That's sad...

eugenepetrenko Jul 4, 2011 at 5:20 PM 
I wish it could also report downloaded packages list (i.e. name, url, version) in some format to a file in order to include it to CI build log. Actually, same applies if I call nuget install packages.config from commandline

mr_miles May 17, 2011 at 9:45 PM 
Regarding workflow, part 1 - what would go into Nuget.config? If it's only to turn the feature on/off, then a project property might be better than another config file? The property could be used to as a condition to determine whether the package updating target runs or not, so keeping it all separate.

I think it also needs to support a "build clean" scenario where packages are cleaned out before the build and downloaded afresh.

smnbss May 17, 2011 at 9:35 AM 
I would add a voice to the contextual menu of the solution: "Update nuget Packages"
This command should
1 - read all the packages.config in the solution folder,
2 - check the packages folder and install any missing package
3 - update references for every project

In a big solution with multiple projects, I would like to be able to do a find replace and change the version of a nuget package I'm using (from v1.1. to v2.2)
and update all the references in one click.

SEWilson May 3, 2011 at 5:34 AM