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: