How does Visual Studio Team Services manage custom or in-house dependencies?

Question

I have a custom build-process that uses a combination of NAnt, Maven Ivy, CruiseControl.Net and a few others to manage the dependencies and handle the continuous integration build process for our projects. And it works great, in all honesty.

One relatively important part in-particular for us, is the ability for us to get an exact version of any given dependency (.dll, .xml. .whatever) from our shared Ivy repository is absolutely paramount to our work, due to different applications requiring different versions of a particular library for different reasons/purposes.

However - I am currently looking into Visual Studio Team Services (http://visualstudio.com) and am experimenting my way along the code check-in/auto-build process, except I cannot see where or how I manage my external/third-party dependencies.

Using Maven's Ivy dependency management/configuration tool, the process is pretty-much flawless and have so much faith in it - what is the Team Services equivalent to this?

My best findings online after hours of searching seems to suggest the NuGet be used for this, and make custom packages for each of my dependencies, but then where/how are these stored and accessed by the Team Services continuous integration build process? Can I store my packages in a NuGet server within Azure? Can I be sure that this is used only by myself?

The best SO posts that I've found so far are:

• Dependency Management/Team Projects in Team Foundation Server 2010
• Dependency management with TFS 2010

...but these still leave me unanswered and maybe I am right off track with this, but need to understand the dependency management process that TFS will follow.

Answer 1

A lot of people just check-in their dependencies into their TFS source code repository (binary files in a lib folder).

A better way is to use a package manager like you suggest. The most common one used in the .Net world is NuGet. You got the right idea, TFS Build just talks to any NuGet server that can be hosted anywhere. Read this blog post for some more details: http://blogs.msdn.com/b/dotnet/archive/2013/08/27/nuget-package-restore-with-team-foundation-build.aspx

Answer 2

TFS and Visual Studio don't have a dependency management tool built-in like Maven Ivy. NuGet is indeed the closest you get, but it's all configured at the solution level and checked into source control. You even need to run your own NuGet server, since TFS doesn't ship with one (unless you want to push them to a public repository, which you'd normally not want).

There are a number of 3rd party solutions that, but the out-of-the-box features simply come down to:

• Check the dependencies into source control (you can change the build process template to do so at the end of a successful build. Your build can always reference the relative path to the required dependency. If you want to be able to change the dependency version without having to change the project files, you can use Workspace mappings to map a specific version of a dependency to a specific folder on the build.
• Configure your build to get NuGet packages and configure your own NuGet server where these packages can be found. TFS 2013 and Visual Studio Online can now automatically fetch NuGet dependencies on build. Which packages are downloaded is still stored in config files in source control, but you can use the NuGet packages file to lock the version or always get a specific tag or version.
• Change the Build process template. This is the most extensive step you can take, but arguably also the most powerful. The default build process template, especially the .12.xaml versions are very simple and straight forward, but you can change the template to do just about anything you want. Grabbing specific dependencies from anywhere could certainly be one of the options. You could also let the Build Process template integrate into Maven Ivy if you'd want to.

As for 3rd party options, TeamCity was mentioned, though it adds a NuGet server, which is pretty easy to host yourself. As might others, but discussing which 3rd party solution might be better than others is against StackOverflow policies.

Answer 3

One possible answer might be TeamCity:

From their website

Using TeamCity as NuGet Server

If for some reason you don't want to publish packages to public feed, e.g. you're producing packages that are intended to be used internally; you can use TeamCity as native NuGet Server instead of setting up your own repository. To start using TeamCity as NuGet Server you need to enable TeamCity server to be a NuGet server by clicking corresponding button at Administration | NuGet Settings | NuGet Server page. Two different links will be displayed on the same page: for public (with guestAuth prefix) and private (with httpAuth prefix) feed. If Public Url is not available, you need to enable the Guest user login in TeamCity at Administration | Global Settings page.

I can't say I've used it but this might help you out with your issue.

Answer 4

Yes you should go with a package manager for managing internal dependencies. We use Nuget as package manager and have an internal Nuget server for our internal dependencies but I'm pretty sure you can host it on azure. Our CI build automatically downloads the packages when running so that shouldn't be a problem. The link @dylan mentioned is the one to use for that.

I haven't used it but you can also look at ProGet which is basically Nuget for Enterprise.

http://inedo.com/proget/overview