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:
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:
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”: