Build improvements in TFS 2010 SP1

Team Foundation Server 2010 Service Pack 1 was released in March. For Build, we contributed dozens of changes to react to the problems reported by customers. In this post, I will list a few of them that can visibly show the work that we did.

No more inadvertently setting Build Quality

When you open the Build Details view, what used to happen was that the focus of the page is set on the Build Quality drop-down box at the top. This drop-down box allows you to select a quality value for the build. Initially, the build has no quality assigned.

This is not the best experience, and here’s why:

1. If you use the arrow keys to navigate instead of Tab, you will end up selecting the build qualities instead of moving to the next UI control of the page.
2. Once a build quality is selected, you cannot set your build quality back to “unassigned”, and the result could be unwanted.
3. Each time you select a new build quality, a request is made to the server to persist your change. This is not very nice for a drop-down list where you can iterating over the values, because each key pressed event costs you a server trip. And it is even worse if you have a remote server that takes a few seconds to reach.

Hence, having the focus on this drop-down list when the page is open could let a user assign a quality for her build inadvertently, mess up her reports permanently, and leave her wondering why Visual Studio is too slow on a simple drop-down selection.

The fix? Simply take away the default focus on this control so selecting build quality will not be done by mistake.

This fix only addressed the first issue, which, as a matter of fact, was the source of complains as it got our customers by surprise. The second and third issues will be addressed in our next release.

No more accidentally deleting Test Results

For RTM, the default deletion list of the retention policies is ‘everything’ including the test results. Not too long before we found out that this behavior is not expected by customers. Test results have their own history and they usually need to stay longer than just a few days. So we changed the default retention policies to delete all build-related things except for test results.

Reduced memory pressure in the Build Service Host

Several customers reported that TfsBuildServiceHost.exe consumes a lot of memory and does not seem to free them properly, causing other processes on the build machine to suffer with memory depletion.

This problem is in our build information tracking system where the build workflow activities are tracked and stored as information nodes on the server. The tracking objects are supposed to be released at the end of the activities in which they are created. In reality, a majority of tracking objects were kept unexpectedly until the end of the build process. Although the allocated tracking objects are finally released, we’ve still got a memory pressure issue that leaves a fragmented heap of the build service host.

A quick comparison of the number and size of the tracking objects right after running a build with a ~30GB workspace without and with the fix is shown below:

	Count (Tracking Objects)	Size (Byte)
Without the fix	500,385	16,012,320
With the fix	39	1,248

 

Improved Performance of the Build Details View

We had a Connect bug about the Build Details view in Visual Studio 2010 RTM being sluggish when opening a large build that has lots of build information nodes. In addition, both the View Summary and View Log pages of this view show all the build errors and warnings, which can make the performance issue worse if there are thousands of them.

The issue in general has been addressed in the next release. For SP1, we ported a fix to move the initial loading to a background thread and limit the number of build errors and warnings being shown on both the View Summary and View Log pages. On the View Summary page, there will be 5 errors and 5 warnings for each project. On the View Log page the number is 50. If there are errors and/or warnings that are not shown, there will be a message to let users know that more can be seen in the build log file.

To change the default limits, the following registries can be overridden:

[HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\10.0\TeamFoundation\Build\UISettings]
"MaxErrorsToShowInDetails"=dword:00000005
"MaxWarningsToShowInDetails"=dword:00000005

Setting these to zero means that there is no limit.

Other hot fixes that got rolled up to SP1

We released a hot fix rollup (build 10.0.30319.341) back in September 2010 which contains several build fixes. These fixes now got rolled up into SP1 as well. Here is the list of build fixes from the KB983504 article:

• The status of the build agent remains unavailable for more than one hour, without changing the status to "Offline" or "Available."
• Duplicate changesets are listed in the build report.
• You connect to a server that is running Team Foundation Server 2008 by using a Team Foundation Server 2010 client. When you right-click an existing build, the Open Process File Location item is unavailable.
• You run a Visual Studio 2008 test project in Visual Studio 2010. When the test fails, the build log shows only one call to MsTest.exe (9.0). Additionally, the test report cannot be published on the server.
• If any build controller goes offline, build drops are not deleted.

 

That’s for now. Hope you’ll enjoy this Service Pack 1.