We’re happy to announce that Supplement to Inside the Microsoft Build Engine: Using MSBuild and Team Foundation Build, 2nd Edition (ISBN 9780735678163), by Sayed Ibrahim Hashimi and William Bartholomew, is now available for purchase.
Get the supplement that helps you drill even further into MSBuild—and maximize your control over the software build and deployment process. Designed as a companion to the popular book Inside the Microsoft Build Engine: Using MSBuild and Team Foundation Build, Second Edition, this supplement extends your knowledge by covering what’s new in Visual Studio 2012 for MSBuild and Team Foundation Build. You’ll also gain a fresh cookbook of examples to help you get productive with UI changes, batching, Team Foundation Server, offline apps, database publishing, and other essential topics.
You can purchase your copy from The Microsoft Press Store, from Amazon, or from Ada’s Technical Books and Cafe.
You can find the TOC in this previous post, which announced our release to the printer.
Enjoy this excerpt from Chapter 2.
In the first part of this chapter, we’ll look at the new features that are available in Team Foundation Build 2012, as well as the improvements to Microsoft Windows Workflow Foundation 4.5 that you can use when customizing or creating build process templates. In the second part of this chapter, we’ll look at how to use some of these new features, step by step.
The installation process for Team Foundation Build 2012 is largely unchanged from Team Foundation Build 2010, but there have been some changes to system requirements as well as improved support for unattended installation, which we’ll cover in this section.
The system requirements for Team Foundation Build 2012 have not changed significantly. The hardware requirements are the same, but Team Foundation Build 2012 now supports the following operating systems:
■ 64-bit version of Windows Server 2008 with SP2 (Standard or Enterprise edition) ■ 64-bit version of Windows Server 2008 R2 with SP1 (Standard or Enterprise edition) ■ 64-bit version of Windows Server 2012 ■ 32- and 64-bit versions of Windows 7 with SP1 (Home Premium, Professional, Enterprise, or Ultimate edition) ■ 32- and 64-bit versions of Windows 8
This means that Team Foundation Build 2012 is not supported on Windows XP, Windows Vista, Windows Server 2003, or 32-bit versions of Windows Server 2008.
Team Foundation Build 2012 also supports unattended installation by allowing configuration to be done unattended using the Tfsconfig command-line tool. There are three steps to performing an unattended installation of Team Foundation Build 2012:
1. Create an unattended configuration file. A stub configuration file can be created by running tfsconfig unattend /create /type:build /unattendfile:unattend.ini.
2. Perform an unattended installation by running tfs_server.exe /quiet from the installation media. Because installing Microsoft .NET Framework 4.5 requires a reboot if it’s not already installed, it may be necessary to run this command, reboot, and then run it again before Team Foundation Build 2012 is fully installed.
3. Perform an unattended configuration by running tfsconfig unattend /configure / unattendfile:unattend.ini using the Unattend.ini file created in step 1.
Tip The Tfsconfig.exe file is located in %ProgramFiles%\Microsoft Team Foundation Server 11.0\Tools once Team Foundation Build 2012 has been installed
In the “Team Foundation Build 2012 cookbook” section later in this chapter, we’ll look at how to implement a common unattended installation scenario in more depth.
Perhaps the biggest change in Team Foundation Build 2012 is one that isn’t technically part of Microsoft Visual Studio 2012 or Team Foundation Server 2012—the introduction of Team Foundation Service.
The Team Foundation Service is a cloud-based version of Team Foundation Server, which allows you to use Team Foundation Server in a matter of minutes, without having to set up your own infrastructure.
A Free Plan is available, which supports up to five users with an unlimited number of team projects. It also supports a wide variety of the features available in the on-premise Team Foundation Server, including the following:
■ Version control (including Git support) ■ Work item tracking ■ Agile planning tools ■ Build (currently in “preview”) ■ Test management (currently in “preview”)
Currently, the Build service is in “preview,” which means it can be used without charge. According to the service’s pricing page, when the feature exits this “preview” mode, a certain number of builds will be available for free each month (if you’re on the Free Plan), and builds beyond that will incur an additional charge.
The Team Foundation Service supports both on-premise build controllers and agents (where they’re hosted on your hardware and network) and a single build controller/agent (per account) hosted in the cloud. To use the hosted build controller/agent, simply select Hosted Build Controller from the Build Defaults tab of the New Build Definition dialog box, as shown in Figure 2-1.
On this tab, you may also notice a new option for the drop location (now called Staging Location) that allows you to put the build outputs into version control. This option is available only for build definitions on the Team Foundation Service and is very important because the Team Foundation Service does not have access to a Universal Naming Convention (UNC) path to drop the build outputs.
This path needs to be placed under the drop’s folder at the root of each team project, and a subdirectory will be created automatically under the selected path based on the build definition’s name. If you choose to delete drops as part of your retention policy, the drop’s folder in version control will be destroyed so that that space can be reclaimed by the database.
Each time you build using the Hosted Build Controller, you’ll notice a short delay before the build begins. This delay is because the build controller/agent is reimaged automatically before each build. The Hosted Build Controller is a single machine per each account, so it will be shared across all the team projects and build definitions in that account. It is the quickest and easiest way to start using builds in the Team Foundation Service, but it does have a number of limitations that may affect its suitability for your purposes. This machine will run only a single build at a time, which may be a problem if you have a large number of build definitions or need to process a large number of builds.
If you determine that the Hosted Build Controller won’t meet your needs, then you can use on-premise build controllers/agents, which is discussed in the “Team Foundation Build 2012 cookbook” section of this chapter. Some of the limitations of the Hosted Build Controller are
■ The build process does not run with administrative privileges on the build controller/agent. ■ The build controller/agent may not have the software installed that your build process requires. A list of the software installed on the build controller/agent is available at http://tfs.visualstudio.com/en-us/learn/build/hosted-build-controller-in-vs/#software. ■ The most significant limitation is that the Hosted Build Controller cannot build Windows Store applications. ■ Because the build process does not run with administrative privileges, you can’t install software as part of the build process template to work around this limitation. However, you can use software that can be XCopy-deployed (including NuGet packages). ■ The build controller/agent has 1 GB of free space for source code, intermediate outputs, and build outputs. ■ The build process is limited to a maximum execution time of 1 hour. ■ The build controller/agent does not run interactively, so it cannot run tests that require an interactive session (such as Coded UI tests). ■ You do not have the capability to log on to the build controller/agent machine, which may affect your ability to debug custom build process templates.
You can still customize build process templates in the Team Foundation Service, just as you can for Team Foundation Server. However, you need to keep these limitations in mind to ensure that your customizations work in the hosted environment. You can detect programmatically whether you’re running in the Team Foundation Service by using the IsVirtual property of IBuildServiceHost, which is accessible using the ServiceHost property from either IBuildController or IBuildAgent.
This section covers the user interface (UI) enhancements that are in Visual Studio 2012 and Team Foundation Server 2012 Web Access, including the significant update to Team Explorer.
Visual Studio 2012 includes a significant update of the Team Explorer user interface, which is now streamlined to make common tasks easier to complete and to provide “at-a-glance” information within Team Explorer itself. The hierarchical tree that had been in previous versions is now replaced with a series of pages that focus on specific tasks. Figure 2-2 shows the Builds page of Team Explorer, which replaces the Builds tree node from Visual Studio 2010.
The My Builds section (see Figure 2-3) automatically shows your six most recent builds, which allows you to see at a glance the outcome of recent builds that you’ve triggered. Double-clicking a build takes you to that build’s details, and right-clicking it allows you to take actions quickly, such as retaining a build, retrying a failed build, or reconciling your workspace after a gated check-in. You can also click Actions and My Builds to open Build Explorer in a form that is filtered based on builds you queued.