Feedback Request for using NuGet Without Committing Packages

nuget, code, open source 0 comments suggest edit

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:

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!

Found a typo or error? Suggest an edit! If accepted, your contribution is listed automatically here.

Comments

avatar

9 responses

  1. Avatar for Brian
    Brian April 27th, 2011

    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.

  2. Avatar for David Gottlieb
    David Gottlieb April 27th, 2011

    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.

  3. Avatar for Michael McGuire
    Michael McGuire April 27th, 2011

    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.

  4. Avatar for Josh Smeaton
    Josh Smeaton April 27th, 2011

    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!

  5. Avatar for Mohamed Meligy
    Mohamed Meligy April 27th, 2011

    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.

  6. Avatar for Szymon
    Szymon April 27th, 2011

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

  7. Avatar for Shane Whittet
    Shane Whittet May 1st, 2011

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

  8. Avatar for Steve Smith
    Steve Smith May 27th, 2011

    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).

  9. Avatar for David
    David August 26th, 2011

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