Blog

Access multiple TFVC repositories in a Build 2015 definition

19 Jan, 2016
Xebia Background Header Wave
When you have a TFS project collection with many Team Projects, it’s a common practice to have a “shared” project containing a collection of commonly used libraries. This library may consist of Checkin policies, Build Activities, MsBuild tasks and Custom MsBuild targets. The alternative used to be to check in these files with each team project, running the risk of them getting fragmented quickly, leaving you in a situation that is very hard to maintain.

Nowadays I’d opt to put most of these dependencies in a vsix or in nuget package and distribute them using a custom gallery or the upcoming Package Management features in Visual Studio Team Services. 3rd party solutions like ProGet and MyGet can also fill in this demand.

Unfortunately, when migrating from one system to another, you don’t get the option to change the whole solution structure or the way 3rd party dependencies are retrieved all at once, so you may need to mimic the old “shared repository” pattern when migrating build from XAML over to Build 2015.

When setting up a new build definition in Build 2015, you’ll be asked what source control system you want to use, we’re going to pick Team Foundation Source Control in this case:

When we navigate to the Repository page, you’ll see that the Repository matching your current team project was selected by default and that a default mapping has been created:
In the old XAML build editor of Visual Studio you could easily map sources and artifacts from other team projects as well, but when you open the browse window in Build 2015 this doesn’t seem to be possible:
XAML
Build 2015
However, looks are deceiving in this case. Even though the file picker is limited to the currently selected Team Project, in reality there is no such limitation. If you manually enter the paths in the mapping you’ll see that they work just fine:
blogspot
It’s a bit unfortunate that the editor isn’t working here, nor in any of the other tasks, so when you browse for the location of a powershell script, or a solution somewhere in a project that isn’t your main repository you’re on your own. 
This, however, is a limitation of the UI and not of the build system itself.
So, there you have it. With a bit of manual data entry you’ll be able to port your old builds from XAML to build 2015 without having to immediately change this pattern.

Remark on build scope

It may be that you’ll run into a security error when fetching sources from multiple team projects, there is a setting we’ve ignored so far, which can limit a build definition to the repository it’s scoped to. By default this setting is set to “Project Collection”, but if you’re having issues accessing the other repositories, it may be that in your case it was set to “Project”. To build from multiple repositories, you’ll have to change the scope back to “Project Collection”:

Jesse Houwing
Jesse is a passionate trainer and coach, helping teams improve their productivity and quality all while trying to keep work fun. He is a Professional Scrum Trainer (PST) through Scrum.org, Microsoft Certified Trainer and GitHub Accredited Trainer. Jesse regularly blogs and you'll find him on StackOverflow, he has received the Microsoft Community Contributor Award three years in a row and has been awarded the Microsoft Most Valuable Professional award since 2015. He loves espresso and dark chocolate, travels a lot and takes photos everywhere he goes.
Questions?

Get in touch with us to learn more about the subject and related solutions

Explore related posts