Monday, 17 December 2012

Diagnosing problems with Process Explorer

I recently upgraded an instance of Team Foundation Server 2010 to the 2012 version. The core upgrade process went very smoothly. The problem came with my customised build templates which used a custom activity written in C#. I was expecting one error, which I tried to fix before even attempting a build. This first error was that my custom activity was written against the TFS 2010 client assemblies:

Microsoft.TeamFoundation.Build.Client, Version=, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
Microsoft.TeamFoundation.Build.Common, Version=, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
Microsoft.TeamFoundation.Client, Version=, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
Microsoft.TeamFoundation.Common, Version=, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
Microsoft.TeamFoundation.WorkItemTracking.Client, Version=, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a

These had to be changed to the TFS 2012 (Version assemblies. So I upgraded and rebuilt the assembly holding my custom activity.

However, running a build after the upgrading my custom activity still gave me an error:

TF215097: An error occurred while initializing a build for build definition \[Team Project Name]\[My Build Name]: Cannot create unknown type '{clr-namespace:StealFocus.TfsExtensions.Workflow.Activities;assembly=StealFocus.TfsExtensions}UpdateBuildNumber'.

For some reason my "UpdateBuildNumber" class could not be created. That type could not even be found.

Time to poke around and see what is happening.

After checking some obvious things (were all dependencies available on the Build Agent, checking Fusion Log etc), I used Process Explorer ( to look at the "TFSBuildServiceHost.exe" process and see if my assembly was even loading.

Starting up Process Explorer, I got a list of all processes on the local machine. I know I'm looking for "TFSBuildServiceHost.exe" as that is the executable for the Team Build service.

I can look at the detail of "TFSBuildServiceHost.exe", including all loaded .NET assemblies.

Looking down the list of loaded assemblies, my "StealFocus.TfsExtensions.dll" (which holds my custom activity) is not loaded at all, so it looks like there's quite a fundamental problem.

The thought occurred to me that I compiled my upgraded custom assembly against .NET 4.5, perhaps the TFS Build Agent is a .NET 4.0 application. This would mean the TFS Build Agent would be unable to load my assembly. As a rule of thumb, a .NET application cannot load assemblies from a later .NET Framework version. As an aside, the CLR version indicated as "v4.0.30319.17929" in the information above is misleading, the .NET Framework 4.5 still uses the CLR v4.0. The CLR saying "v4.0.30319.17929" did not mean it was a .NET 4.0 application.

So I rebuilt my upgraded assembly against .NET 4.0 and the build completed successfully. Looking into the detail with Process Explorer once more, I saw the following:

My assembly ("StealFocus.TfsExtensions.dll") had indeed loaded.

Problem solved.

So Process Explorer was a very useful tool to see what was happening under the hood. It showed me that my assembly was not loaded, which triggered my thought process about .NET Framework versions.

About Me