Executing (Multiple) Target Injection in TFS

It seems I am never going to be rid of finishing these automating events! One problem that we tackled today dealt with TFS target injection, where you want to call other targets at different points in the build process. An example of this is when you want to wire a target before/after something like SolutionToBuild and ConfigurationToBuild, perhaps to do a little work before the build starts. In this case, the build was chained to **another** build to do a get on a separate VC instance, and build a related solution beforehand. There was also some WIT stuff to be done too.

Fortunately, TFS Build makes this pretty easy through the use of the Before* or After* targets (which are easily grafted from Microsoft.TeamFoundation.Build.targets), most you will ever need are existing but if you need a different one you can use a CallTarget with a MSBuild task. This can get even cooler, because you can actually start to build chained dependencies through something like:

[xml]

[/xml]

Pretty neat!

Share

Using A Junction Point Drop Strategy In SharePoint Development

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:

[xml]
$(BinariesRoot)\projectX
[/xml]

Viola!

Share