Visual Studio Team System (VSTS) Blog - by Neno Loje : Team Build Server

Unable to publish test results from Visual Studio to TFS

neno — Sat, 30 May 2009 20:54:41 GMT

Error message similar to:

username@servername (mailto:username@servername) 2008-10-13 2:21:50 0.28 MB 10/13/2008 3:19:14 PM Failed Access to the path '\\DropFolder\Buildname_20080723.3\TestResults\fd8883e0-2153-44c6-8671-6d6db460c4a8\uesrname 2008-10-13 _02_21.trx' is denied.

Cause: Permission issue

A Workaround can be found in the KB article 958726.

Hotfix for Team Build 2008 SP1: Reducing project-to-project references in build log (KB958845)

neno — Sat, 31 Jan 2009 13:10:30 GMT

From Aaron Hallberg blog:

[…] change in TFS Build SP1 which reduced build log noise by cutting out the build steps for project-to-project references […] the fix in SP1 didn't actually fix the problem, at least not completely.

[…] As such, if a project was referenced by 10 other projects the fix in SP1 would reduce the number of spurious build steps from 10*3 to 9*3 rather than removing them altogether.

A hotfix is finally available that will address the remaining parts of the problem […]

VSTS MVP colleague Mathias Olausson reports:

“before SP1 the build time was about 2h 30 min, with SP1 build time in average 65 minutes and with the build hotfix we’re now down to less than 40 minutes. The build log has changed from 5500 lines down to 550.”

Download hotfix: TFSBuild TargetsNotLogged property fails to cut down noisy builds

Additional Info: KB article 958845

Turn off label deletion when deleting builds

neno — Fri, 09 Jan 2009 00:50:10 GMT

By default a build label is deleted when the corresponding build gets deleted.

In TFS 2008 SP1 you can change that behavior by modifying the web.config file (on the TFS AT in folder %ProgramFiles%\Microsoft Visual Studio 2008 Team Foundation Server\Web Services) to:

<appSettings>
<add key="PreserveLabelsOnBuildDeletion" value="true" />
</appSettings>

(Thanks to Buck Hodges for this tip).

Facts about Running Builds in Parallel with Team Build

neno — Wed, 09 Jul 2008 19:57:02 GMT

TeamBuild

can build one build definition from a single Team Project at a time.
can build multiple build definitions from different Team Project.

MSBuild

has the capability to use multiple CPUs to build projects in parallel and therefore speed up your builds.
This multiproc feature can be leveraged in your Team Builds.

Thanks Grant for pointing out those facts.

Screen Gallery: Installing Team Build 2008

neno — Sun, 11 May 2008 11:15:01 GMT

Screenshots from a successful Team Build installation

TFS 2008: Team Build doesn't get subfolders of team build type folder by default

neno — Sun, 16 Mar 2008 01:05:03 GMT

In TFS 2005 subfolders of your team build type folder were copied recursively to the build temp directory. In TFS 2008 only the contents w/o recursion is copied.

To change this behavior, Aaron tells us, you need to modify the following line

<add key="ConfigurationFolderRecursionType" value="Full" />

in the TfsBuildService.exe.config on your build machine.

Enjoy!

Documentation: Team Foundation Server SDK (online version)

neno — Sat, 23 Feb 2008 13:55:34 GMT

From the contents:

Team Foundation Server Extensibility

Team Foundation Server SDK Architecture

How to: Run Team Foundation Server SDK Samples

Team Foundation Core Services

Work Item Tracking Extensibility

Source Control Extensibility

Data Warehouse Extensibility

Reference for Team Foundation Server SDK

Link: http://msdn2.microsoft.com/en-us/library/bb130146(VS.80).aspx

How code churn is calculated in TFS 2005/2008

neno — Sat, 23 Feb 2008 13:51:28 GMT

Code churn [1] in TFS 2005 and TFS 2008 is calculated using a very simple algorithm: inserted + changed + deleted lines [2].

This is done independently of the contents of the line, which means that everything - incl. comments, blank lines, etc. - is counted.

[1] http://blogs.msdn.com/mohamedg/archive/2007/12/04/code-churn.aspx

[2] http://msdn2.microsoft.com/en-us/library/ms244698(VS.80).aspx

Enable logging to troubleshooting Team System issues

neno — Fri, 24 Aug 2007 15:07:53 GMT

Here’s a list of how to enable logging for the various client and server components of VIsual Studio Team System:

TFS Client (Visual Studio IDE and command line tools):
devenv.exe.config (for Visual Studio IDE), tf.exe.config (for command line tools) as described in Ed Hintz on TFS Client Tracing. If you mainly want to measure performance the web service performance dialog can be added as a trave listener and is very helpful in that case.

Team Foundation Server
You can turn on tracing globally or for specified components only.

Team Foundation Server Activity Logging
Records web service method calls. See here how to enable and here, here and here how to analyze the data.

Team Build Server
Look into the config file for instructions on how to enable tracing, typically found in: %ProgramFiles%\Microsoft Visual Studio 8\Common7\IDE\PrivateAssemblies\tfsbuildservice.exe.config.

Team Test Load Agent
You can turn on logging in the QTController.exe.config (for the Controller) and QTAgentService.exe.config (for the Agents). More information can be found here.

You might also be interested in other useful logging options for .NET.

[Screen Gallery] Setting up a dedicated build machine: Installing & Configuring Team Foundation Build

neno — Tue, 01 May 2007 11:25:34 GMT

Note: Make sure to read the Installation Guide before installing this software.

What do I need it for?

You need "Team Foundation Build" to set up a dedicated build server.

Why should I do that? Can't I use the TFS itself?

A build usually compiles code (which needs a lot of processor power). You don't want your primary TFS to timeout while a build runs.

Where to find it?

On the Team Foundation Server CD in the build directory.

What do I need?

Dedicated machine with Win XP Professional SP2, or Windows Server 2003 SP1 (Std./Ent.) or higher with .NET Framework 2.0 installed (as listed here).
Username and password of your TFS Service Account which needs to be entered during install.

What must be done prior to installing?

Nothing, the cleaner the machine (clean in the sense of no additional software installed), the better...

What should be done after it's installed successfully?

If you are running tests as part of your build process, you have to install the Visual Studio Team Edition for Software Testers (VSTE/ST).
If you are running static code analysis as part of your build process, you need to install the Visual Studio Team System for Software Developers (VSTE/SD).
If you want to automatically generate a deployment report out of an deployment diagram as part of your build process, you'll need to install the Visual Studio Team Edition for Software Architects (VSTE/SA).
Of course you can alternatively install the Visual Studio Team Suite instead of the individual Team Editions.
If you use call further software during the build process (like for example NDoc, Sandcastle, NAnt, FinalBuilder, ILMerge, Dotfuscator, ...) make sure to install them as well.

Comment by the author: Of course it's not nice & clean to see Visual Studio on a build box and I'm sure Microsoft will fix this by providing a lightweight, xcopy-deployable Test runtime in future.

Addendum: We now have a solution we use internally for our customers which run large build labs in Virtual Environments where we don't install Visual Studio but just a small MSTest runtime.

[Team Build] Why is the "DropBuild" target after the "AfterDropBuild" target?

neno — Wed, 31 Jan 2007 14:55:19 GMT

People tend to ask me why the order for the build-in Team Build targets usually is:

BeforeSomething
CoreSomething
AfterSomething
Something

(Replace "Something" with a action like "Get", "Compile", "DropBuild", or similar ...)

You can find the execution order of the Team Build Targets published in the MSDN Library:

Order of Target Execution

The order of execution of the targets is in the following list.

BeforeEndToEndIteration

BuildNumberOverrideTarget

InitializeEndToEndIteration

BeforeClean

CoreClean

AfterClean

Clean

InitializeBuild

BeforeGet

BeforeLabel

Label

AfterLabel

InitializeWorkspace

CoreGet

AfterGet

PreBuild

BeforeCompile

CoreCompile

AfterCompile

Compile

GetChangeSetsAndUpdateWorkItems

PostBuild

BeforeTest

CoreTest

Test

AfterTest

PackageBinaries

TeamBuild

BeforeDropBuild

CoreDropBuild

CopyLogFiles

AfterDropBuild

DropBuild

EndToEndIteration

AfterEndToEndIteration

Let's look at the four targets related to copying the files to the drop location (BeforeDropBuild, CoreDropBuild, AfterDropBuild, DropBuild). DropBuild is the target you would specify on the command line if you only want to drop the build to the drop location and is defined as follows:


<Target Name="DropBuild"
DependsOnTargets="$(DropBuildDependsOn)" />

and the DropBuildDependsOn property looks like this:

<PropertyGroup>
<DropBuildDependsOn>
    BeforeDropBuild;
    CoreDropBuild;
    CopyLogFiles;
    AfterDropBuild;
</DropBuildDependsOn>
</PropertyGroup>

So it's intentially empty, because a build target can only specify on which targets it depends. So DropBuild is only a structure element to ensure Before, Core And AfterDropBuild will be invoked in the designated order.

Before and AfterDropBuild are empty as well (waiting for you to override them if you want to customize the process):


<Target Name="BeforeDropBuild" />


<Target Name="AfterDropBuild" />

And finally CoreDropBuild does the work (and it's recommended NOT to override this target)

<
<Target Name="CoreDropBuild"
Condition=" '$(IsDesktopBuild)'!='true' and '$(SkipDropBuild)'!='true' "
DependsOnTargets="$(CoreDropBuildDependsOn)" >


<CreateItem Include="$(BinariesRoot)\**\*.*" >
<Output ItemName="FilesToCopy" TaskParameter="Include" />
</CreateItem>
<Copy
SourceFiles="@(FilesToCopy)"
DestinationFiles="@(FilesToCopy ->'$(DropLocation)\$(BuildNumber)\%(RecursiveDir)%(Filename)%(Extension)')"
ContinueOnError="true" />
</Target>