New book: Supplement to Inside the Microsoft Build Engine: Using MSBuild and Team Foundation Build, 2nd Edition

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.

• • Extends your knowledge of MSBuild with all-new coverage of Visual Studio 2012
• • Shares additional hands-on insights and guidance from two expert authors
• • Provides a cookbook of examples to study and reuse

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.

 

CHAPTER 2 What’s new in Team Foundation Build 2012

 

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.

Installation

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.

System requirements

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.

 

Unattended installation

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.

Team Foundation Service

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
https://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.

User interface (UI) enhancements

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.

 

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.

 

My Builds

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.