CODEWITHSUNDEEP
visual-studiotfs
Nick
Nick

Reputation: 871

Can a solution have projects from two TFS collections

We are thinking of making a distinct collection for code that is shared between our software products. We would then have a collection for the software projects. This would be done for organizational purposes. Would it be possible for a solution to reference c# projects that are in two different collections?

Upvotes: 2

Views: 2031

Answers (2)

jessehouwing
jessehouwing

Reputation: 115025

A solution can have files from anywhere, since they need to be mapped to a loal disk for Visual Studio to open them, but when spreading the code over multiple collections Source Control integration will break. Team Explorer requires all code to come from the same collection, and it favors solutions where all code is from a single team project, in those cases the other features will work best.

Other features in VSTS and TFS will be harder to use when your work is spread across multiple projects and/or collections. Test Plans, Agile tools, Team capacity and a few other items are purely scoped to the Project level. working in multiple projects at the same time will make it much harder for a team to use the tools properly. Many TFS consultants implement a "One project to rule them all" strategy because of these reasons. Putting all code and all work in one teamproject.

The XAML and 2015 build engine can only access sources from a single Project Collection at a time. So while it's possible to setup a number of local workspaces that each map to different team projects and/or project collections, this is not available when using the standard build servers that ship with TFS. Other build tools, such as Team City can be linked to multiple Source Control providers at the same time.

Now that it's possible to have multiple Git Repositories under the same Team Project, that approach makes even more sense.

Other things that will be harder may include branching structures, it will be very hard to manage the different versions of your code when they're spread across collections, since Labels and Branches can't cross collections and are hard to maintain when working in multiple projects.

A better solution for you would probably be to have your shared code in a separate team project or project collection, but not include it directly in your other projects in the form of Visual Studio Projects. Instead, have your shared projects stored as NuGet packages, either on a private NuGet feed or on a VSTS account with Package Management enabled.

That way your other projects will build faster (which can be significant when setup correctly), will use the binary versions of your shared libraries and have less unwieldy solutions.

One disadvantage of putting all code in a single team project or project collection is that it's harder to maintain the security. Project Collections for a natural boundary inside TFS, one that's harder to accidentally misconfigure or to break out from.

Upvotes: 4

Claudius
Claudius

Reputation: 1911

As @jessehouwing said solutions can have files from multiple collections. Each collection has a local workspace from where you attach project/files to your solution.

Where I disagree is that this is actually a good idea. There is no problem having 10+ collections, each for specific purpose.

For example 1 for generic projects that nobody will update unless necessary. One to store scripts. Basically think of it as library bookshelf. All similar stuff to some degree should be kept close.

Another plus is a security since one team can have access to some collections but not other. It is an obvious plus.

As to time difference, does really 1-2 sec make difference to anybody. Add one more agent and you will save time because locally building makes no difference.

As to Labels specific purpose strategy helps to overcome those problems.

Upvotes: 1

Related Questions