How to Properly Use NuGet with Team Development?

Question

So I would like to use NuGet to manage the various projects I use for a specific project my team and I are working on. Up to this point, I have placed my .js library files in the /Scripts directory of my web solution (ASP.NET MVC 2) and referenced those. Of course, this was manual and was annoying to manage during upgrades, etc.

Now that I am using NuGet, I realize that the entire goal of NuGet is to make this fairly painless. In addition, it appears that I shouldn't have to check my packages into my repository (AKA I don't need to manage my external libraries anymore). However, when I grab jQuery (for example) from NuGet, it places its specific files in the /Scripts directory of my project.

Where I get confused - what, if anything, should I check into source control at this point? Do I still check in the /Scripts directory?

In addition, if someone else is working on this project and checks out the solution from source control, are the packages automatically downloaded (assuming the solution comes with a valid packages.config)?

I'm just trying to clarify a couple points before we start using NuGet full-time.

Answer 1

There are two scenarios for NuGet vs VCS: to check-in or not to check-in, that's the question. Both are valid in my opinion, but when using TFS as VCS, I'd definitely go for a no-checkin policy for NuGet packages.

That being said, even when using a no-checkin policy for NuGet packages, I'd still checkin the content changes that those NuGet packages have done to my projects. The \Scripts folder would be checked-in in its entirety (not selective, not ignored).

The no-checkin policy for packages to me means: not checking in the \Packages folder (cloak it, ignore it), except for the \Packages\repositories.config file.

As such, you are effectively not committing any NuGet packages, and when using Enable-PackageRestore from the NuGetPowerTools (this will be built-in in NuGet v1.6 just around the corner), any machine that checks out the code and builds, will fetch all required NuGet dependencies in a pre-build step. This is true for both local development machines as for build servers, as long as Enable-PackageRestore is enabled in your solution and points to the correct NuGet repositories (local, internal, external).

If you think about it, when installing a NuGet package that only adds references to some binaries, you'd already be doing the samething in a no-checkin scenario: you would not commit the \Packages folder's subfolders, but still, you'd commit the project changes (the added reference).

I'd say, be consistent (for any type of package), whether it contains binaries only, content only, or a mix. Do not commit the packages themselves, do commit the changes to your sources. (if only to avoid the hassle of looking up what changed content-wise)

Answer 2

NuGet, like Nexus, are artifact repository (artifact being any type of deliverable, including potentially large binary).

The side-effect is for you to not store in an VCS (Version Control System) elements that:

• wouldn't benefit from VCS features (branching, merging)
• would increase significantly the size of the VCS repository (no delta or weak delta storage)
• would be quite hard to remove from a VCS repository (designed primarily to keep the history)

But the goal is for you to declare what you need (and let NuGet fetch it for you) instead of storing it yourself.
So you can version /Scripts as a placeholder, but you don't need anymore to versioned any of its content now fetched automatically.