Code Analysis in Team Build 2010

Code Analysis provides an executable set of rules that can be checked during a build to ensure standards and practices are being adhered to during development. This functionality is a great addition to a team build, and the tools required come as part of the Team Build Agent 2010 installation. Recently I’ve been doing some digging into how the Code Analysis is setup and triggered during a build.

Configuring Code Analysis

The first step to having code analysis run as part of your team build is to configure the rule sets and execution of analysis during the build of your project files. To do this, right click your project file and bring up the properties interface. Go to the Code Analysis tab and check the Enable Code Analysis on Build check box. This defines a constant that MSBuild will use to determine if the analysis should be run or not. You then need to pick your rule set, which can be set in two places. Firstly you can set it on the projects you want to run analysis against individually.

Project Properties

Configuring code analysis in project properties

This will get you started with Code Analysis, but once you turned on the analysis there must be a better way to get a view of the rule sets across the board for your solution right? If you right click your solution file and open up the properties interface, then click the Code Analysis Settings item you’ll see something like this:

Configuring rule sets in solution properties

Configuring rule sets in solution properties

This will give you a nice view of the code analysis rule sets for all of the projects in your solution. Something to note here is that the rule settings can be chosen on a per configuration basis. You can also use the ‘All Configurations’ option to set them across the board.

Once you’ve enabled Code Analysis and picked a rule set you should be able to run a local build and see a set of warnings shown for those rule violations that exist in your code. We’ve now got code analysis in our local build!

Code analysis warnings

Code analysis warnings in local build

Configuring Team Build to execute code analysis

Having local code analysis configured is a great place to start. Adding support for executing the code analysis in Team Build is the next step on the road to ensuring consistency in code. Setting up code analysis is really quite simple in the default build template.

First open or create the build definition you’d like to run code analysis in. Once you’ve got the Build Definition screen open, head to the Process tab. On this tab, you should see a parameter in the Basic group titled ‘Perform Code Analysis’. The default value here is to use ‘AsConfigured’ which will ensure execution for those project files that specify the code analysis constant with the rule sets defined. You can also turn it on with an ‘Always’ setting, or off with a ‘Never’ setting.

Build Definition

Configuring code analysis in your build defintion

How does code analysis get run?

There are a lot of good posts on how FxCop itself works, so I won’t cover it here. I also won’t cover writing custom rules or custom rule sets.. What I will cover is how it gets called during part of your Team Build.  My images here are based on the default template, so the activities used are all included in the standard install.

The settings for Code Analysis are passed into the executing build workflow as arguments. You can check these by opening the XAML, and clicking the ‘Arguments’ button at the bottom of the workflow designer.

Build Arguments

Build arguments on workflow designer

The list you see are the arguments defined for the workflow as a whole. If you’d like to see the arguments scoped to a specific activity, use the ‘Variables’ button next door.

If you start with a collapsed view (recommended) you’ll need to navigate down the activity tree to locate the Run MSBuild for Project activity which is an instance of the MSBuild activity. If you click this activity and open your properties window you’ll see that the activity accepts a  ‘RunCodeAnalysis’ parameter which is bound to the ‘RunCodeAnalysis’ argument specified for the build workflow.

Activity Configuration

Properties as configured for MSBuild activity

Pretty simple so far right? Time for some reflectoring to see what actually occurs here. Once we’ve loaded the Microsoft.TeamFoundation.Build.Workflow assembly into reflector we can navigate through the Activities namespace and locate the MSBuild activity. Once there we’ll a look at what exists inside. What you’ll see is pretty much what you’ve seen in the properties dialogue in Visual Studio. Lots of properties to allow the configuration of the build call. What you didn’t see in Visual Studio was the list of helper methods used inside the activity. There’s one particular method we’re interested in here which is titled ‘GetFxCopPath’.

Reflected MSBuild Activity

Content of the MsBuild activity viewed in Reflector

If we disassemble this method we’ll see that the method checks a registry key to find the FxCop executable path and returns that to the caller.

GetFxCopPath Dissasembled

GetFxCopPath Method Content

Digging a little deeper into the activity we find it utilises an internal code activity known as GetCommandLineArguments. This activity contains the following code snippet in its execute override:

GetCommandLineArgs Snippet

GetCommandLineArgs method content

This code sets up the execution of Code Analysis based on our build and project settings, and the path to the FxCop executable that was located via the registry key earlier. From here on, code analysis is run as per the normal MSBuild process based on these settings we’ve provided.

Known Issues

Unfortunately due to a bug discovered very late in the release cycle the install for Code Analysis does not execute on x64 build servers. This means you won’t see code analysis running despite correct configuration. The work around for now is to install a Visual Studio SKU that includes Code Analysis on the build machine to get the FxCop installation.


Making use of Code Analysis during a Team Build is a great way to help ensure a good level of consistency across your code base. Armed with this article, and some knowledge of how FxCop inspects code and applies rules you should now be ready to incorporate this useful tool into your automated build process.


3 thoughts on “Code Analysis in Team Build 2010

  1. Pingback: Tweets that mention Code Analysis in Team Build 2010 « Steve Godbold --

  2. Rory Primrose

    Just a minor point. My preference is to enable code analysis on Release build configuration only. I find that it slows builds down too much in Debug which is where most of the dev happens. I then change over to release to rebuild and run tests before a check in.

    1. Siresh

      Hi all, need help on

      We have incorporated code analysis in our project, below is the structure of the project:

      We have set Calculating Code analysis for a.sln which folders like b,c,d.

      When we compile a.sln it’s referencing to b1.csproj file and c1.csproj file.

      ASK: Is it expected that the Code analysis numbers gets generated for b.sln and c.sln as a.sln is referencing (b1.csproj file and c1.csproj) while compiling?

      Please let me know your inputs on the below scenario any help or advice is much appreciated.



Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s