Code metrics command line tool

[UPDATE 3/24/12]  You can find a real code metrics activity here as part of the Community TFS Build Extensions.

Cameron Skinner has announced a new command line tool for generating code metrics.  We’ve long gotten requests to be able to generate code metrics from the build.  Prior to this tool, code metrics could only be generated from within the Visual Studio IDE.

I installed it this morning.  The readme link on the download page tells you where it is installed, which is %programfiles%\Microsoft Visual Studio 10.0\Team Tools\Static Analysis Tools\FxCop.

I wanted to do the simplest possible thing (i.e., quick and dirty!) I could to give it a try this morning as part of a 2010 TFS build.  I grabbed the copy of Professional Application Lifecycle Management I happened to have sitting here on my desk at home (thanks, Martin) and turned to page 504 to follow the ZIP archive example to get me started.  You can get the entire build chapter for free (same with the manual testing chapter).

  1. Open up the default build process template in the WF designer (e.g., open the build definition, click Show Details on the Process tab, click on the hyperlink, and double click the file)
  2. Scroll to the bottom of the workflow.
  3. Drag an InvokeProcess activity into the build process.  Drop it in as the last activity in the Try, Compile, Test sequence (drop it after the symbol activity, just before the catch block).
  4. Right click on the InvokeProcess activity and show parameters
  5. Set the following properties, fixing up the paths for your machine and the hard-coded assembly name (like I said, I went for the quick and dirty just to see it work).
    1. Arguments: String.Format(“/f:””{0}”” /o:””{1}”””, System.IO.Path.Combine(BinariesDirectory, “ConsoleApplication1.exe”), System.IO.Path.Combine(BinariesDirectory, “out.xml”))
    2. DisplayName: Code Metrics
    3. FileName: “D:\Program Files (x86)\Microsoft Visual Studio 10.0\Team Tools\Static Analysis Tools\FxCop\metrics.exe”
  6. Drop a WriteBuildMessage into the bock for the standard output and a WriteBuildError for the error output.
  7. Set the following for WriteBuildMessage
    1. Importance: Microsoft.TeamFoundation.Build.Client.BuildMessageImportance.High
    2. Message: stdOutput
  8. Set the following for the WriteBuildError
    1. Message: errOutput

Then I checked in my build template changes and ran a build.  The drop folder now contains a file called out.xml with the code metric data in it.

You can find documentation on all of the activities here on MSDN.


[UPDATE 1/30/10]  Martin sent me the links to the build and testing chapters, which I’ve added above.

Comments (4)

  1. midas79 says:

    I think this is a big step forward for code metrics, but I still dream of a day when this data can be rolled into the warehouse and reported on…see…/813ac234-aef8-4ae6-9351-e067338a08f5 for others with the same vision.

  2. buckh says:

    BenJoe, I agree and hate that we don't have it more integrated with the rest of the system.


  3. This is very cool.  However,  the metric data is reported as attributes rather than elements in the resulting XML output.  This makes the results file cumbersome to sift through programmatically among other things.

    W3schools points out the following problems with using attributes over elements:

    •attributes cannot contain multiple values (child elements can)

    •attributes are not easily expandable (for future changes)

    •attributes cannot describe structures (child elements can)

    •attributes are more difficult to manipulate by program code

    •attribute values are not easy to test against a DTD

    Done the other way (i.e. the way code coverage reports, test results,  and most xml in general is produced), metric data could be correlated to code coverage data and/or test results easily in Excel or whatever you choose to import your well-formed XML results to.  

    Specifically, the XML report is produced this way

    <Metric Name ="Maintainability Index" Value="77" />

    as opposed to


    There are plenty of workarounds to this, but out the box it would have been nice to see it mesh with other report XMLs generated by Visual Studio.

  4. buckh says:

    Paul, thanks for the feedback.  I will pass it along to the team.