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

Chaining SharePoint Builds Status

So I am still in migration hell and fixing some build code. One of the problems we just ran into was chaining build events. Consider if you had SharePoint project X which contained and Exec command that triggered SharePoint project Y. The goal of their custom build is to query into the build status of SharePoint project Y, and display the build status in SharePoint project X’s build status. Put simply, I needed a mechanism where Project Y build status, like whether it returns Success, Partial Success, etc.

Fortunately, this isn’t terribly difficult using the Exec task to execute a command leveraging the exitcode to get the status. This looks like the following:

[xml]






[/xml]

The exitcode return will be an integer, which is easy to correlate to the respective return values, Failure is 100, Partial Success is 1, Success is 0, Unknown is -1, and Unrecognized Command is 2.

Share

Using TFS for Mixed C#/Managed C++ SharePoint Projects

Currently, I am doing a massive TFS migration for a health insurance company, and as part of the migration I am verifying build events for all their projects. Actually I am verifying almost 10 gigs of them, so it’s going to take me the better part of a month! Now aren’t you jealous.

I was migrating some managed C++ / C# SharePoint projects and noticed something very, very interesting.

With mixed language managed C++ projects, particularly, or at least in my case, when bundled with other C# projects, it might be noticeable that some of the compiled C++ projects don’t make it to the drop location. However, some do. While it appears sporadic, those that are referenced from the C# projects are still copied. After investigation I found the root cause is that managed C++ projects actually don’t consider some MSBuild properties. In this case, the problem is the lack of observance of the OutDir property. To understand this, consider the way that Team Build harvests outputs for managed C++ projects for the drop location, they override the OutputDirectory property (in vsprops). So if CustomizableOutDir is set to true, getting those compilations to the drop folder because a manual push.

How to fix it? Get TFS 08 SP1 which has a modified CustomizableOutDir property that lets you work around this! If this option is not on the menu, you can work with CompilationOutputs item group, or something similar, so that you can ultimately override some task with a Copy task to support cloning the files to the drop location.

Share