Build Retention Policies in TFS2010

October 11, 2009

I noticed some interesting changes for the Build Retention Policies in TFS2010 (Beta 1):

  • possible differences between retention policy for triggered and manual builds vs private builds

    You will be able to set another retention policy on private builds: builds that are run by the enabled Gated Check-in trigger.

  • extra What to delete column

    You will be able to specify more in detail what information must be deleted when the retention policy kicks in.


MSTest.exe exited with code -2146233082 during Team Build

September 17, 2009

Recently I was faced with a failure in a Team Build caused by MSTest that crashed when firing up the Unit Tests.

MSBUILD : warning MSB6006: "MSTest.exe" exited with code -2146233082

Digging a bit deeper and running the Unit Tests manually with MSTest on the build server via the command line showed me a dialog box with the following notification:

MSTest.exe has encountered a problem and needs to close. We are sorry for the inconvenience.

Nothing more, nothing less! Hmm … Note that this behavior only surfaced after SP1 of Visual Studio 2008 and TFS 2008 was installed on the build server. Before, everything worked fine. On my local development pc (with SP1 of Visual Studio 2008) all Unit Tests run without any problems.

Let’s take a look at the eventviewer to get some extra information of what’s going wrong here …

Two interesting events were logged:

  1. .NET Runtime version 2.0.50727.3053 – Fatal Execution Engine Error (7A035E00) (80131506)
  2. Faulting application mstest.exe, version 9.0.30729.1, stamp 488f21a6, faulting module mscorwks.dll, version 2.0.50727.3053, stamp 4889dc18, debug? 0, fault address 0x001c5e00.

After searching for these errors on the web I came across some blog posts that mentioned the same Fatal Execution Engine Error but the scenario where this error occurred was totally different. It had something to do with Visual Studio disappearing unexpectedly but apparently there was a hotfix available on Microsoft Connect for this Fatal Execution Engine Error. So, with no other options at that moment I decided to go for the hotfix and see what happened.

The hotfix indeed did fix the problem, but I’m still puzzled what actually caused the problem. Strange was that certain Unit Test assemblies did run well on the build server while others even didn’t get started due to the above conditions …

[I did also log this error on the Testing forum of Visual Studio Team System]


Generating ClickOnce packages with Team Build 2008

September 7, 2009

Last week I spent way too much time on troubleshooting an issue with generating a ClickOnce package with a Team Build. Generating the package was actually not the problem, but running the application always resulted in …

Reference in the manifest does not match the identity of the downloaded assembly x

It was clear that something was wrong with the manifest, but I could not find what was keeping the application from launching. I checked and double checked the build script and the way the package was built but could not find an indication of the above error. Publishing the application from within Visual Studio 2008 seemed to work without any hitches and it was then that I noticed the following setting in the Application Tab of the Start Project in Visual Studio.

Visual Studio 2008 embeds by default a manifest inside an assembly. This means that the ClickOnce executable was using this default manifest instead of the manifest that was generated with Team Build. Switching to the other option to not generate a manifest with Visual Studio did solve the issue!

Hopefully I can save someone’s time with this blogpost!


More fine-grained permissions in TFS2010

September 3, 2009

Recently (in TFS2008) I was stuck with the fact that I could not split up the permission to create/modify builds and the permission to create/modify build agents. In certain enterprise environments it might be necessary to revoke the right from development teams to create/modify build agents. Build agents may be for instance controlled centrally by an operations team that manages all build servers. In TFS2008 both tasks belong to the “Administer a buid” permission.

The good news is that TFS2010 will offer a lot more fine-grained permission sets! You will now have the possibility to set permissions on the Team Project Collection, on the Team Project, on the Build Definition level and on the Version Control repository!

  • Team Project Collection
    • Administer shelved changes
    • Administer test controllers
    • Administer warehouse
    • Administer workspaces
    • Alter trace settings
    • Create a workspace
    • Create new projects
    • Delete a team project
    • Delete team project collection
    • Edit collection-level information
    • Make requests on behalf of others
    • Manage build resources
    • Manage process template
    • Manage work-item link types
    • Trigger events
    • Use build resources
    • View build resources
    • View collection-level information
    • View system synchronization information
  • Team Project
    • Administer test environments
    • Create test runs
    • Create team project
    • Delete test runs
    • Edit project-level information
    • View project-level information
    • View test runs
  • Build Definition
    • View Builds
    • Edit build quality
    • Retain indefinitely
    • Delete builds
    • Manage build qualities
    • Destroy builds
    • Update build information
    • Queue builds
    • Manage build queue
    • Stop builds
    • View build definition
    • Edit build definition
    • Delete build definition
    • Override check-in validation by build
  • Version Control
    • Read
    • Check Out
    • Check In
    • Label
    • Lock
    • Revise other users’ changes
    • Unlock other users’ changes
    • Undo other users’ changes
    • Administer labels
    • Manage permissions
    • Check-in other users’ changes
    • Merge
    • Manage branch

Great! There are a few permission that are new and that I certainly want to look into a bit deeper … but now let’s go back to my problem in TFS2008 and how to fix it in TFS2010. Right clicking the Team Project Collection brings me to the permissions on the Project Collection level.

The permission to Manage build resources allows people to create and modify build controllers and agents.

Right clicking Builds brings you to the permissions on the build definition level.

The permission to Edit build definition allows people to create and modify new build defnitions.


DYK #3 : retain build indefinitely

March 17, 2009

 
If you hold on to a specific Team Build retention policy (new since TFS2008), you might lose all valuable build information of a particular build that you actually wanted to keep.

There’s an option available via the Build Explorer to retain builds indefinitely!


DYK #1 : IIS not required for Team Build

February 22, 2009

 
DYK = Did You Know?

Internet Information Server (IIS) is not required to be installed for a TFS 2008 Team Build machine

The application server for TFS 2005 still used .NET Remoting to communicate with the Team Build machine, but as from TFS 2008 the communication is set up with Windows Communication Foundation. The WCF service runs in a managed Windows Service (TfsBuildService.exe).


Test Impact Analysis

February 5, 2009

 
Test Impact Analysis is a new feature that will be part of Visual Studio Team System 2010 and it will enable developers to view which Tests are impacted by your latest code changes that are not checked in yet. I was struggling a bit to get it up-and-running but once you know the drill, it’s quite straightforward. The fact is that you need to have published test results by a Team Build on the previous stable situation.

How to set it up?

  • Create a new Team Build for your solution that also triggers your UnitTests and publishes the test results :
    1. Select Solution to Build and select your tests to run

    2. Enable Get Impacted Tests

    3. Enable Publish the Test Impact Data

  • Enable Code Coverage for appropriate assemblies

  • Queue a new build of the newly created Team Build
  • Change some code that would impact a Unit Test
  • Open the Test Impact View Window

  • See the results …

    This window reads as follows : 2 Unit Tests are impacted by my latest code changes that are not yet checked in. The AddTest Unit Test should be rerun because of changes made to the Add method.

I hope that this process will be simplified a bit more in the final release. If you don’t get it working immediately, check the Build log in search for Test Impact. Note that the Build log in TFS2010 has improved a lot! Maybe a topic for one of my next posts …


Build Controllers and Build Agents

December 1, 2008

 
New for Team Builds in Team Foundation Server 2010 is the concept of Build Controllers. In the previous versions of Team Foundation Server (2005/2008), you were only able to assign a Team Build to a specific Build Agent. This means that when the Build Agent is offline or in failure, your Team Build won’t run and you will have to manually switch to another Build Agent.

In Visual Studio Team System 2010 you must assign the execution of a Team Build to a specific Build Controller instead of a Build Agent. The Build Controller will now be responsible for managing a custom pool of Build Agents and will select the rightBuild Agent to run the Team Build. In the screenshot below you can see that the Default Controller has a pool of 2 Build Agents : Default Agent and Pieter’s Agent. A Build Controller – like the Build Agent – may have 4 different states : Enabled, Disabled, Unreachable and Initializing.

New is also the tagging system for Build Agents. You may for example tag a Build Agent as a WinServer2008 machine or as VeryPowerful.

These tags may be used during the configuration of your Team Build. When a Team Build needs to run on a Windows Server 2008 machine, you can enforce this in the Build Process setup on the ReservationSpec of the agentScopeActivity ["Select an Agent and Build"].

When preparing a demo for my VISUG session last week, I noticed that on the VS2010CTP (October 2008 Release) there’s only one Build Agent assigned to the Default Build Controller and I couldn’t find a way to assign an extra Build Agent to the Default Build Controller. Brian Harry forwarded my question to Jim Lamb and Aaron Hallberg of the Team Build and they finally came up with the magic : for now it’s not possible to do it via the user interface, but for now you need a command line to do it …

tfsbuildservicehostconfig.exe
  agent /new /name:"Pieter's Agent"
  /buildDir:"C:\$(BuildDefinitionPath)"
  /BuildController:"Default Controller"

This exe runs in the Team Build Folder of %Program Files%\Microsoft Visual Studio v10.0 Team Foundation Server. After executing this command, an extra TFS Build Agent should pop up in your Task Manager …


Source Server for TFS Builds

October 23, 2008

 
This is not yet a widely known practice in the field, but setting up a Source Server for TFS Builds in an enterprise development environment can be extremely valuable.

My friend and ex-colleague Jelle Druyts wrote a few months ago an excellent blog post about how to set up a Source Server for TFS Builds.

Anyone who will reference assemblies that are built with a source server enabled TFS Build will be able to debug those assemblies in the original source code … great for framework code for instance!

When an assembly is “source server-enabled”, the pdb file will contain the full path and the exact version of the file in source control that was used to build that assembly. If the debugger then enters a method, Visual Studio automatically downloads that correct file, places it in a local cache, and opens it for debugging. This is super sweet!

If you follow the guidelines of Jelle, you need to add the custom target RunSourceServerIndexing somewhere in your Team Build script, but he doesn’t specify exactly where you need to include this.

Well, you have two options : you can do this in your TFSBuild.proj file or you can also put this custom target in an underlying .targets file to make it more reusable. The TFSBuild.proj file is the easiest option, but I would recommend an underlying .targets file. In fact it’s always a good practice to make an underlying .targets file for all your common Team Builds. The idea is to make your .proj file as clean as possible and put all the logic and commands in an underlying .targets file.

In the image above you can see that I’ve created a specific target for all Compuware Team Builds on the Build Server. This .targets file must be imported in all TFSBuild.proj files and to enable source server for my Team Builds, I’ll just need to create a boolean variable in my TFSBuild.proj and pass it to the Compuware.targets file.

The Compuware.targets file will do all the required steps in the background. Note that the default is set to false for the variable SourceServerIndexing.

If you follow this pattern for other build tasks, you will end up with a clean TFSBuild.proj file and you will only need to pass booleans (and/or other variables) to the underlying .targets file that will contain all the reusable build tasks. Note that automatically all TFSBuild.proj files will import the default Microsoft.TeamFoundation.Build.targets file. Make sure that you never edit this master file, because it may jeopardize the working of your Team Builds when you need to migrate to another version of MSBuild.

Another small issue I came across when following the guidelines : the location where to drop the TFIndex.cmd file may be different than pointed out in the document (due to a different default location of the Debugging Tools). If that’s the case you must also check the location of this file when you set the custom target RunSourceServerIndexing.

If you haven’t taken the time to explore the possibilites of a Source Server for your TFS Builds, please do so now! You won’t regret!


No code coverage result with Team Build?

October 10, 2008

 
When creating a new Team Build with the Build Wizard in TFS 2008, it may be possible that you won’t have code coverage results while you have this option enabled in your testrun configuration file. This depends on how you selected your tests to run …

  1. If you have chosen to run tests that are listed in a Test List, then there won’t be any problem : code coverage results will be available because all testrun configuration settings will be picked up in the testrun configuration file via the .vsmdi file.
  2. If you have chosen to run tests with the TestContainer option, then the testrun configuration file is not picked up because there won’t be any trace of a .vsmdi file in your build project file. You may fix this by manually adding the following line to your .proj file.

    <RunConfigFile>$(SolutionRoot)\$filename$.testrunconfig</RunConfigFile>

    This line (to be added in PropertyGroup of .proj file) will pick up the test run configuration file and will control the way tests are run.


Follow

Get every new post delivered to your Inbox.