VSTS2008, TFS2005 MSBuild Woes

This last week I have been working with a client to create MSBuild scripts for build automation. We ran into various issues and after various web searches and blog mining we got everything working today. Although I am not a big fan of posting links to items that have been blogged about rather frequently, I decided to provide a rundown of our issues and the blog posts that helped us fix them because of the large amount of sites that had wrong or misleading information.

Our first issue was the fact that our applications were built using Visual Studio Team System 2008 targeting both the 3.0 and 3.5 versions of the framework, but our Team Foundation Server was still 2005. There were several posts about creating custom tasks or using Powershell, but the simplest resolution was to simply use the FileUpdate task in the MSBuild script to modify the solution file. This was not actually in a blog post, but in the comments to this one. I would add to this approach that you change it back somewhere after the CoreCompile target fires. I opened the solution on the TFS server itself a few times to troubleshoot some other errors and without changing the file you get the conversion wizard when you try to open the modified solution file.

This worked for our 3.0 projects for our WCF services, but our web application needed the 3.5 version of the compiler due to our use of C# 3.0 syntax such as automatic properties and object initializers. Again there were several posts with various resolutions (some involving create another build server with a modified MSBuild.exe) but most were not acceptable to the client. We eventually called the DEVENV for VSTS2008 directly from the command line to build the web application solution. This worked better than I expected and even itemized build errors in the build log just as if it were part of the core compile. Calling the DEVENV was outlined in several blog posts also, but a fair amount of these had incorrect or incomplete syntax. Finally we found this post that provided the correct syntax and a very clear explanation of why it works. This resolution also helped us overcome the glaring omission of MSBuild support for setup projects.

So after many, many failed builds we finished our build scripts today that compile all of our solutions, build the setup projects, copy the MSI files to a network share, and then use PSEXEC to install the application on our development server. We have a separate batch of build scripts for the different branches in the code so within a few minutes I can deploy any branch of the code to our development server (or local machine) for testing. Even with a few days to figure it out the overhead of doing that manually will save us much more time in the long run.