15

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 internal 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

Cole W
  • 15,123
  • 6
  • 51
  • 85

2 Answers2

11

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

Xavier Decoster
  • 14,580
  • 5
  • 35
  • 46
  • +1 I will try this. Thanks for the input. Are you currently using this strategy? – Cole W Oct 07 '11 at 18:59
  • 1
    You're welcome! Yes I am. This is only the consumption part of the story, which is what you asked for. There are also ways to automatically produce packages post-build. – Xavier Decoster Oct 07 '11 at 19:02
  • So when you want to debug one of your internal dlls from a project that has a nuget package for this do you just change your reference to point to a debug version or is your Project's Debug settings pulling the debug dependencies somehow? This is one of the drawbacks I see to having this sort of system. – Cole W Oct 07 '11 at 19:15
  • 2
    Good question! There is a way out since you're using TFS, which has a built-in symbol server. If your internal dlls publish their symbols to the symbol server during the automated build process, and the consuming project is configured to use this symbol server (Visual Studio options), consuming projects will be able to step through your code, just as if they had the pdb's locally. (non-tfs users, could use private symbolsource.org repositories and publish nuget symbol packages). This set-up works for me. – Xavier Decoster Oct 07 '11 at 19:22
  • the consumers will need read permissions on the sources for the internal dll's they want to step through. TFS Source Control security is automatically applied when using the built-in symbol server. To summarize: if you don't have read access to the sources, you won't be able to step through them, which makes sense I think ;-) – Xavier Decoster Oct 07 '11 at 19:36
  • So in order to use Nugget in TFS I have to use the old build system, create a share where I should put all the packages or even worst give my Build Server access to the Internet? – Juan Zamudio Feb 29 '12 at 18:06
  • What's wrong with your Build Agent(s) having access to the Internet? If you really don't want this, then check the packages into source control (and get them from the internet yourself). Doesn't block you from using NuGet on TFS. – Xavier Decoster Mar 04 '12 at 17:51
  • @Xavier Decoster: Whats the benefit of having a Build server with internet access?, and besides our IT guys don't let any server have Internet, and no to answer your question, this does not block me, but it's very annoying. – Juan Zamudio Jun 11 '12 at 22:59
  • @JuanZamudio I feel your pain, been there, done that :) I prefer not to host the internal NuGet repository or feed on a build server (because of the workload, and they usually don't have internet access). Having a network share as a central pkg repository is probably your way out. It requires someone (or something) to put the pkgs on their though. Mirror the pkgs you need from nuget.org. Or have a service in your network (hosted on a machine that does have internet access) that relays all calls to nuget.org (so the build server doesn't talk to the internet directly) :) – Xavier Decoster Jun 13 '12 at 06:43
1

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

Remco
  • 1,713
  • 1
  • 13
  • 14