by Tim Anderson
Builds are an important part of the development process. Tim Anderson checks out the options open to users of Microsoft Visual Studio.
HardCopy Issue: 61 | Published: November 1, 2013
One of the pillars of modern software development is to build frequently and automate everything, to the extent that some teams constrain code check-in so that code that will not build cannot be checked in. Automation is critical for a couple of reasons. The first is to save time and avoid errors, but it goes beyond that. If the build is fully automated, then the scripts that perform the build can be treated as part of the code and so subject to version control, testing, refactoring and the like. Automated builds are also an essential step towards continuous integration, where code is checked in frequently and successful build verified. If developers make conflicting changes then the problem is found immediately and can usually be easily fixed.
By contrast, if developers work separately on their parts of the project for an extended period of time before checking in their code, then there is a higher chance that conflicting changes elsewhere will break the build. Because the changes that caused the conflict may have been made days or weeks before, they are inevitably harder to find and fix.
Blogger Jeff Atwood calls the build server “Your project’s heart monitor” while Martin Fowler at ThoughtWorks notes: “Projects with Continuous Integration tend to have dramatically less bugs, both in production and in process. However I should stress that the degree of this benefit is directly tied to how good your test suite is.” You do not have to embrace the philosophy of Continuous Integration in order to take advantage of a build server, but you cannot do so without it.
Building in Visual Studio
Developers working on small projects may just hit Build in Visual Studio and not worry about what is happening under the covers. However since Visual Studio 2005, your .NET projects are built using a tool called MSBuild, and since Visual Studio 2010, MSBuild has also been used for C/C++ projects.
This is a build accelerator that includes a Visual Studio add-in. It works by building your applications in parallel on multiple machines, exploiting the fact that many CPU cycles lie idle on typical networks. Reducing build time enables developers to work faster, which means that IncrediBuild can soon pay for itself provided that the savings are real – and the speed improvements can be remarkable.
Getting started with the accelerator is a matter of installing the IncrediBuild coordinator on a machine that is always on, and then installing IncrediBuild agents on any other available machines. Where Visual Studio is installed, the agent installs an add-in menu that lets you build from the Visual Studio IDE. Agents can still be installed and assist in builds on machines without Visual Studio. When you build a project, a build monitor shows the activity on the agents in use and reports status.
A project file (extension ‘proj’) in Visual Studio is an MSBuild script and is in XML format, as our screenshot shows. You can also build a Visual Studio project from the command line using ‘msbuild’, and there are a ton of switches for logging, modifying build properties, building in parallel on a multicore machine (use the /m switch) and much more. Building from the command line opens up more customisation options than building from within Visual Studio. Command line builds are also important if you want to call MSBuild itself from a script, or to use integration tools that work outside Visual Studio.
One reason Microsoft separated MSBuild from the Visual Studio IDE was to enable remote builds on machines where Visual Studio is not installed. If you are working in a team, a separate build server is a big advantage. You can build locally to test your own code, but the remote build will be the one that verifies that the solution as a whole builds successfully, and gives the whole team easy access to the latest build. Remote build is integrated into Microsoft’s ALM (Application Lifecycle Management) platform Team Foundation Server (TFS).
Although it is called by Visual Studio, MSBuild has always shipped as part of the .NET Framework. In the new Visual Studio 2013, this changes and MSBuild comes as part of Visual Studio, though it will also be available as a standalone package called Microsoft Build Tools which you can install on build servers or if you want to work without Visual Studio. Part of Microsoft’s rationale for the change is that it will avoid issues where the toolset, such as the actual version of the compilers used, could vary depending on whether you call MSBuild from the command line or from within Visual Studio.
Customising a build
The Visual Studio 2012 IDE lets you customise the build process to some extent. To do this you right-click a project, choose Properties, and go to the Build tab. The Build Events tab lets you add pre-build and post-build commands. These are DOS commands, and you can call out to batch files.
MSBuild has many options that are not exposed here. You can edit the build script in Visual Studio by right-clicking the project and choosing Unload project. Then right-click again and choose Edit to open the XML build script in the IDE. When you are done, close the file and reload the project.
MSBuild understands properties like DebugType and OutputPath. Such properties are gathered into Property Groups which are applied subject to conditions, enabling different properties to be used for Debug and Release builds, for example.
Team Foundation Build
FS includes Team Foundation Build which uses a dedicated build server or servers controlled by Visual Studio, allowing you to create build processes that integrate with your testing and code versioning requirements.
The TFS build process is controlled by a Build Definition which is created and edited within Visual Studio. You get started with a New Build Definition on the Build menu. The Build Definition Trigger determines when the build runs: you can specify a schedule, build on every check-in, or require gated check-in that succeeds only if the build succeeds.
The actual build steps are controlled by a build process template. This is a Windows Workflow XAML file which specifies the projects to build, together with additional workflow items such as the running of automated tests or performing analysis. You can also specify how long to keep builds. Several templates are supplied to fit specific requirements, such as Azure Continuous Deployment which will not only build your solution but, subject to tests passing, deploy it to Windows Azure. This kind of approach enables instant deployment of the latest updates, although of course you must have confidence in your testing procedures. You can also deploy to a staging server before public release.
Microsoft’s Team Foundation Service is a cloud-based installation of TFS which is free for up to five users and includes a Build service which is currently in preview. This Hosted Build Controller has certain restrictions. Build processes must complete in under one hour and not require administrative rights on the build server, for example. If your build requires additional software then you will have to use an on-premise build controller, though you can still link this to the cloud TFS.
Final pricing for hosted TFS has yet to be announced but Microsoft has stated that MSDN subscribers will get access, and that there will be some form of per-build pricing for commercial users.
Third-party build tools
A common issue with large projects is that build time increases to the point where productivity is affected, particularly if you embrace the principle of frequent builds to maintain software quality. Build tools like Xoreax IncrediBuild (see panel) address this by accelerating builds, taking advantage of distributed processing.
Another popular tool is TeamCity from JetBrains. This is a build server which you can use for continuous integration with a variety of development platforms, including Java and Ruby, and not just from Visual Studio. However, Team City does have native support for MSBuild and does integrate with the Visual Studio IDE. Team City also supports distributed builds and can be integrated with Amazon EC2 (Elastic Compute Cloud), suspending and resuming Amazon virtual build servers on demand.
CruiseControl .NET is an open source continuous integration server that is based on CruiseControl for Java. Whenever code is committed the CruiseControl server launches a build to verify whether the modified code builds successfully, and notifies the developer accordingly.