Using NuGet for Internal & External Dependencies in TFS

I'm currently looking at NuGet to solve my dependency problems in TFS and what I wanted to do is to host my own NuGet server that would take care of interna开发者_如何学JAVAl dependencies. I also want to use NuGet to handle my 3rd party dependencies as well. I'm trying to set up automated builds for our company and this is one roadblock I'm trying to overcome with NuGet.

So my question is how do I handle this scenario in which I have to retrieve my dependencies from different servers?

Is there a better way to handle internal dependencies? How is everyone else doing this?

Also just as a note I intend on using NuGet without committing packages to TFS. I planned on using the method outline in this article:

http://blog.davidebbo.com/2011/08/easy-way-to-set-up-nuget-to-restore.html

Glad you're looking into the no commit scenario for NuGet packages on TFS. You can take a look at my blog post on this topic where I explain the concept.

EDIT (2012/06/13): NuGetPowerTools is replaced by NuGet's built-in package restore functionality. However, same concept of changing the PackageSources element in nuget.targets still applies.

You definitely should take a look at David Fowler's NuGetPowerTools. After installing this package, you can Enable-PackageRestore (newly installed command in Package Manager Console), which will add... Enabling package restore will add MSBuild targets to your project files. These MSBuild targets will trigger nuget.exe in a pre-build step and fetch any packages required by your project. No need to check-in NuGet packages in source control, all you need is the packages.config and these msbuild tasks.

To configure multiple, different package sources, you need to set some settings to be used by these MSBuild tasks. One of them is PackageSources. You can set it by editing the NuGet.targets file, which you will find in the .nuget folder once you enabled package restore.

Regarding those package sources, you could set up different internal NuGet galleries, or simply set up different network shares to be used. This is a matter of requirements and preference, so you can choose. All you need to do, is to tell your msbuild targets to use these packagesources. The order in which you define them, will be the order of lookup of packages as well.

Good luck! Xavier

Little update on accepted answer and question:

When using TFS as a buildmachine without visual studio installed on it, you can do the following so the buildmachine automatically uses your custom packageSources (more than 1 in the same solution) without any further configuration of packagesources in your solution.

1. Create a machine default config by placing a NuGet.Config in the root ( C:\NuGet.Config ) by using sample from: http://docs.nuget.org/docs/reference/nuget-config-file

2. Comment out the line with: <add key="repositorypath" value="$\External\Packages" />

   Otherwise your packages gets expanded in C:\$\External\packages\'. When commented out, the config gets chained and the right directory will be used.

3. Config your needed packagesource(s).

For more Info about other options (e.g. user specifc) see: http://docs.nuget.org/docs/reference/nuget-config-file (bottom of the page).