4
votes

Copied original question from MSDN forums here but was not solved within TFS 2010. We are using TFS 2012.

I have two solutions in their corresponding folder e.g.

SolutionA\SolutionsA.sln SolutionB\SolutionB.sln

Each solution has Gated Check-in build configured; i.e. two build definitions GatedSolutionA and GatedSolutionB.

Now the situation is, if I check in changes in both folders together TFS shows a dialog box to select build(drop down with GatedSolutionA, GatedSolutionB) to run against the changeset. My changeset has breaking changes in solution B and non-breaking changes in Solution A. i.e. Build GatedSolutionB would fail but GatedSolutionA would pass.

When I select GatedSolutionA to build against my changeset, TFS checks it in, which in turn leaves the solution B in broken state and purpose of Gated check-in is defeated for Solution B.

If I change the trigger to CI for build definitions, TFS queues both builds.

What I am looking for is same behaviour i.e. All the Gated builds are queued and if one of them fails, changeset should be rejected.

Note: I don’t want to create single build definition for both the solutions. Also, I know we can avoid this problem to happen by creating two separate changesets, but this is generally happening when developers are not aware that they have some files being checked in for solution other than they are working on .

Has anything improved or changed between VS/TFS 2010 and TFS 2012 to accommodate this scenario?

EDIT

I'll try and clarify with a scenario.

SolutionA (we'll call StandardCalculator) contains 2 projects, ProjectA and ProjectC. ProjectA is a console application called StandardCalculatorUI and ProjectC is a class library called CalculatorLogic.

SolutionB (we'll call AdvancedCalculator) contains 2 projects. ProjectB is a console application called AdvancedCalculatorUI and the same ProjectC (a class library called CalculatorLogic)

ProjectC implements public methods for Add, Subtract, Divide and Multiply.

ProjectA calls the functionality for Add and Subtract from ProjectC.

ProjectB calls the functionality for Divide and Multiply from ProjectC.

GatedSolutionA build definition builds SolutionA (and thus ProjectA and ProjectC)

GatedSolutionB build definition builds SolutionB (and thus ProjectB and ProjectC)

Now with SolutionA open i DELETE the Multiply and Divide methods from ProjectC, because ProjectA doesnt use them (but unknowingly ProjectB (in SOlutionB)) does).

I check in my code and am presented with which Gated build definition to check against, (Becuase GatedSolutionA and GatedSolutionB have workspaces mapped to include ProjectC).

If I select GatedSolutionA then the checkin will succeed and thus be checked in, unknowingly breaking SolutionB.

What i want it to do is queue against both GatedSolutionA and GatedSolutionB, not force me to pick one.

1
You want the build definition to check all the solutions build, but you don't want to add all the solutions to the build definition?stuartd
does my edit/scenario help or not lolKyle
Create a solution that contains all the projects for both A and B and gate that?Edward Thomson
So, you're saying you have some common class libraries that many of your solutions will reference. When you check one of your solutions into TFS, you don't want it to accept any changes to one of those common class libraries if it would break another solution that might be using it? Have I got that right? Similar to this - stackoverflow.com/questions/13497295/…user2447953

1 Answers

1
votes

Edward gave the answer that I've used. You have to create a new build definition.

We solved a similar scenario by creating a separate solution that includes all of the projects. That solution is used by a separate gated build definition. You still have your other build definitions but the trigger would be manual (not gated).

So you would have 3 solutions: StandardCalc, AdvancedCalc, and BothCalcs. And 3 build definitions. During development you don't use the all-inclusive solution.