A client was asking me this today so I decided to make a quick note and send a link :)
In TFS 2010 when trying to make Sequential builds (i.e. for one you have several interdependent solutions in your automation strategy) in the DefaultTemplate XAML file you have to change the
. It should be noted that this is a lot different than TFS 2008. In TFS 2008, in the TFSBuild.proj file the solutions were just ordered correctly and made use of the BuildSolutionsInParallel property. This also required changing the setting for the MaxProcesses in the tfsbuildservice.exe.config file on the build server to a value greater 1, and also to restarting the build service on the build server. This is a lot more cumbersome than changing the type tag mentioned above.
It’s my last day of my TFS migration, which I will admit I am pretty happy about being complete with. Everything goes into testing for the next couple weeks, so it’s time to sit back and see what people can break.
An interesting point came up today on the second to last project we were converting for build automation. One of the solutions composed of multiple projects employs a separate third party pickup program for deployment of its respective packages, and because of its nature this scheme is not mutable. Off the cuff, this is obviously a no brainer to configure the build drops, but the requirement became slightly more complex. This particular program required a junction point drop, so when a solution structured with multiple projects is assembled it would output project contents under $(BinariesRoot)\project ($(BinariesRoot) being where TFS Build wants to place your binaries during a build, TFS Build sets $(OutDir) to $(BinariesRoot)), as opposed to restricted to the default solution structure. This could be for any number of projects within the solution, $(BinariesRoot)\projectX, $(BinariesRoot)\projectY, $(BinariesRoot)\projectZ, etc.
The solution to this is to use $(CustomizableOutDir) (false by default!) which will use the project settings instead of being overridden by TFS Build. So in each .csproj file you would have:
While fixing builds for my current project, and I’m now finally about half way through em, one problem that bubbled up was that the previously employed build manager had attempted to put together some code to have a build based on compilation success/failure of his SharePoint projects to generate work items. Now, at first glance his code looked correct to me (I’ve stripped it down a stitch):
Nothing about that at first glance looked wrong, but he was getting the error:
A Work Item could not be created for failures in build ‘build’. Please verify that the work item type ‘Task’ is supported in team project ‘proj’ and it has field ‘Microsoft.VSTS.Build.FoundIn’ defined.
Now this problem implies that there wasn’t some of the required foundation laid down before the aforementioned code was integrated. Basically, a work item type Task defined in your team project, then you need to create that first. So bascially hack up the work item type definition file with those definitions, and you are good to go!