Feedback Request for using NuGet Without Committing Packages

• Apr 26, 2011
• 9 Comments
• Print

When installing a package into a project, NuGet creates a packages.config file within the project (if it doesn’t already exist) which is an exact record of the packages that 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 committed to source control. The reason for this is that certain files from the package, such as assemblies, are referenced from their location in the packages folder. The benefit of this approach is that a package that is installed into multiple projects does not create multiple copies of the package nor the assembly. Instead, all of the projects reference the same assembly in one location.

If you commit the entire solution and packages folder into source contral, and another user gets latest from source control, they are in the same state you are in. If you omitted the the packages folder, the project would fail to build because the referenced assembly would be missing.

However

This approach doesn’t work for everyone. We’ve heard from many folks that they don’t want their packages folder to be checked into their source control.

Fortunately, you can enable this workflow today by following David Ebbo’s approach described in his blog post, Using NuGet without committing Packages.

But in NuGet 1.4 we’re planning to make it integrated into NuGet. We will be adding a new feature to restore any missing packages and the packages folder based on the packages.config file in each project when you attempt to build the project. This ensures that your application will compile even if the packages folder is missing at the time, which might be the case if you don’t commit it to source control.

Requirements

We have certain requirements we plan to meet with this feature. Primarily, it has to work in a Continuous Integration (CI Server) scenario. So it must work both within Visual Studio when you build, but also outside of Visual Studio when you use msbuild.exe to compile the solution.

For more details, please refer to:

• The Spec on CodePlex
• The discussion thread to provide feedback.

If you have feedback on the design of this feature, please provide it in the discussion thread. Also, do keep in mind that this next release is our first iteration to address this scenario. We think we’ll hit the primary use cases, but we may not get everything. But don’t worry, we’ll continue to release often and address scenarios that we didn’t anticipate.

Thanks for your support!

What others have said

Brian Apr 27, 2011 3:21 AM

# re: Feedback Request for using NuGet Without Committing Packages

I'm doing something like this in my CI process. I have a local NuGet server that hosts all external packages we use along with all internal packages. The only thing I check into source control is packages\repositories.config then I have a custom build task which executes before anything else in my build script. The setup is something like this

<SetupNuGet RepositoryPath="$(NuGetPackages)\repositories.config">
<Output TaskParameter="Packages" ItemName="Packages" />
</SetupNuGet>
<Exec Command="$(NuGet) i %(Packages.Identity) –Source $(NuGetSource) –o $(NuGetPackages)" />

The SetupNuGet task contains a real simple piece of code which is

var xml = XElement.Load(RepositoryPath);
Packages = xml.Elements("repository").Select(n => n.Attributes("path").Value).ToArray();


I've also been playing with the source so you can point NuGet.exe at the repositories.config file just like you can a packages.config and it will pull down all the packages that are needed.

David Gottlieb Apr 27, 2011 3:46 AM

# re: Feedback Request for using NuGet Without Committing Packages

Phil,
This is excellent.
We follow the recommended model by Microsoft for branching and merging which is:
Main, Development, Release. Main being the branch that is always on test, Development well, being development. And release being your release branches to production.

Within each of those we have a Bin and Src directory. The Bin directory contains any external dependencies referenced by that project or projects in that product and Src containing your source files. Do you think that the flexibility will ever be introduced as to where those assemblies might get stored? If we install a Nuget package, we would want them to go to that Bin location so that they can be checked into TFS.

Michael McGuire Apr 27, 2011 3:50 AM

# re: Feedback Request for using NuGet Without Committing Packages

I like David's suggestion also. Obviously , because the scenario of handling the packages being checked-into source control is already handled, you would want to work on this new scenario first. But it would be nice to be able to choose where the packages are stored, instead of always having to default to the "packages" folder under the solution.

Josh Smeaton Apr 27, 2011 8:36 AM

# re: Feedback Request for using NuGet Without Committing Packages

It has always bothered me that recommended practise (in some circles) is to NOT store binaries in source control. As far as I'm concerned, a check in should contain everything required for either a deployment or a development environment. This allows a new developer to get up to speed quickly, and deployment to be as simple as a checkout/clone.

There are 3 possible solutions as I see it.

1. Write a post checkout script / deployment script / development script to fetch dependencies if they don't exist. Yuk.

2. Modify package management tools to auto-fetch for you; this would need to be combined with #1, as not all dependencies will be satisfied via a package management tool.

Or.. my favourite..

3. Make source control systems smarter! Don't keep differentials of binary files. What's wrong with a .hgbinaries file or similar for tagging the files you want to store un-versioned?

Mercurial has the 'BigFilesExtension' which makes a pretty good effort at #3. Fairly DRY, don't you think?

However, may as well be talking about stored procs vs direct table access. We're not all going to agree, so kudos on supporting both camps!

Mohamed Meligy Apr 27, 2011 9:49 AM

# re: Feedback Request for using NuGet Without Committing Packages

I think at this very point in time it's so nice that you can get the Nuget solution and build and so even without having Nuget.

Also, the build server / CI tool regardless which one used keeps working seemlessly regardless whether somebody used NuGet or not.

Maybe later in .NET vNext when hopefully Nuget is integrated as part of VS and MSBuild, not having to check-in packages folder would make some sense, but for now, I think we should have it the way it is.

Szymon Apr 27, 2011 6:08 PM

# re: Feedback Request for using NuGet Without Committing Packages

Thanks for this, Phil. How soon will you be renaming your site to 'NuGet official Blog'? ;)

Shane Whittet May 01, 2011 11:29 PM

# re: Feedback Request for using NuGet Without Committing Packages

Great idea, as long as the firewall folks can handle allowing nuget.org from the build servers!

Steve Smith May 27, 2011 5:59 AM

# re: Feedback Request for using NuGet Without Committing Packages

If nothing else it would be nice if package authors would produce both "full" packages (with samples, docs, etc) as well as binary only packages, so that those of us who are currently storing /packages in source control can do so without it causing excessive bloat (I'm looking at you, NServiceBus 168MB package).

David Aug 26, 2011 6:28 AM

# re: Feedback Request for using NuGet Without Committing Packages

So did this ever get implemented? I was poking around with 1.4 today and didn't see anything like it.

What do you have to say?

Title:

Name:

Email: (never displayed) (will show your gravatar)

Website:

Comment: Allowed tags: blockquote, a, strong, em, p, u, strike, super, sub, code

Please add 4 and 6 and type the answer here: