I broke the build this week. Without touching any code, for a project I wasn’t even working on.
SharePoint 2010 is still packing on its freshman fifteen. It’s a fair assumption that even if you are rocking this newer version of the collaboration platform, there is still plenty of MOSS 2007 / WSS 3.0 work being done within earshot. Add a shared resource like Team Foundation Server to the mix, and things can start to get interesting for the portal development team.
So there I was, well on my way to achieving automated check-in build goodness for my current SharePoint 2010 project. The good folks at MSDN have supplied instructions for just such an occasion, and I followed them to the proverbial T, availing the necessary version 14 assemblies to our TFS-sanctioned build machine. Shortly thereafter, my shiny new build was running green, and the hills were alive with the sound of continuous integration. Then, a knock at the entrance of my cubicle.
“Jon, do you know anything about this ‘SharePoint 2010 Reference Assemblies’ folder on the build server?”
Yes. Yes I did.
My colleague politely went on to explain that the build for their MOSS 2007 site had suddenly and mysteriously begun to break that afternoon. In reply, I donned the hair shirt and dug in to find a fix. Soon, I had arrived at a simple enough patch for this little inter-version SharePoint awkwardness, and I brought it here to share with you today.
The Key Is The Key
The most lightweight of all the changes recommended in the MSDN article was the addition of a single Registry key to the build server, indicating the location of the aforementioned SharePoint reference assemblies folder. I found that once this key was removed, the MOSS team’s build woes had dissolved, and mine had returned.
With no other build server available, the simplest solution was to add or remove the key from the server’s Registry at the start of each build, using a pair of .reg files and a command line call to regedit from within each build script.
This is the file used to add the key, for SharePoint 2010 builds:
Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v2.0.50727\AssemblyFoldersEx\SharePoint14]@] @="C:\\Program Files\\Reference Assemblies\\SharePoint"
And here, for SharePoint 2007 efforts, is the corresponding one used to remove the key:
Windows Registry Editor Version 5.00 [-HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v2.0.50727\AssemblyFoldersEx\SharePoint14]@]
Once those files have been created, you can add them directly to the appropriate solution by right-clicking on the Solution node in Visual Studio’s Solution Explorer pane, and selecting Add > Existing Item.
Assuming that your projects already have Team Builds configured, add a BeforeCompile Target to the TFSBuild.proj file in each, using the Exec task to merge the appropriate .reg file with a call to regedit /s, like this:
<Target Name="BeforeCompile"> <PropertyGroup> <RegFile>$(SolutionDir)\pre-build.reg</RegFile> </PropertyGroup> <!-- Merge the pre-build .reg file --> <BuildStep TeamFoundationServerUrl="$(TeamFoundationServerUrl)" BuildUri="$(BuildUri)" Message="Preparing Build Server"> <Output TaskParameter="Id" PropertyName="StepId" /> </BuildStep> <Exec Command="regedit /s "$(RegFile)"" /> <BuildStep TeamFoundationServerUrl="$(TeamFoundationServerUrl)" BuildUri="$(BuildUri)" Id="$(StepId)" Status="Succeeded" /> </Target>
Now SharePoint 2007 and 2010 are building together, in perfect harmony. Just like in that Eddie Murphy /Joe Piscopo song.
Oh, All Right
Okay, it’s not perfect harmony. Should the builds coincide, one of them will fail, depending on who wrote to the registry last.
Nevertheless, there is something to be said for good enough. Especially when there are more important and less nerdy things to tighten down than the continuity and integrity of your continuous integration.