Code Coverage in Visual Studio 2010

It’s been far, far too long since I’ve updated my blog, but I wanted to quickly cover what’s new in Visual Studio 2010 for code coverage (Premium and higher SKUs).  Almost all of the changes are under the covers, but some are noteworthy:

• Support for x86-64 instrumentation (native, mixed, and platform-specific managed code) and collection on a 64-bit Windows OS.  To utilize this support in VS, set the host platform to “x64” in the test settings.  From the command line, use the tools in “%ProgramFiles(x86)%\Microsoft Visual Studio 10.0\Team Tools\Performance Tools\x64”.  NOTE: the vsperfcmd/vsperfmon you use must match the architecture of the process you’re collecting data from.  Hopefully this will be fixed in the future.
• Support for ASP.NET collection in IIS under Vista+ from within Visual Studio.  Due to Session 0 Isolation (a security feature of Vista+), code coverage collection was prevented from working within VS.  Collection had to be performed manually using the command line tools.  In an elevated Visual Studio 2010 instance, Session 0 collection now works correctly.
• Support for concurrent code coverage sessions in Visual Studio 2010 or Team Foundation Build 2010.  Previously, code coverage collection was restricted to a single test run in a Windows session, so if multiple test runs were taking place at the same time with code coverage collection enabled, one could possibly fail saying the code coverage monitor was already running.  This was occasionally observed in previous versions of Team Foundation Build when a test run had code coverage enabled.  Now, each test run’s collection is isolated from one another, so this limitation has been removed.
• Eliminated the common cause of “out of memory” errors from the TFS Coverage Analysis Service (CoverAn) that was responsible for merging code coverage data published against a Team Foundation Build.  The service has been replaced with a background job that is capable of efficiently merging very large sets of coverage data.  This change also eliminates the requirement that the service identity has to be granted access to the build drop location to perform its work.
• Added the System.Diagnostics.CodeAnalysis.ExcludeFromCodeCoverageAttribute class to System.dll.  This attribute can now be applied to classes, methods, and properties to exclude the collection of code coverage data.  Instrumentation still respects the DebuggerNonUserCode and DebuggerHidden attributes to prevent instrumentation.  However, as these attributes are also used by the debugger when stepping, consider switching to the ExcludeFromCodeCoverage attribute instead.
• Revamped the analysis API to be more efficient and consistent.  I will try to touch on this bullet point in a future blog post describing how to analyze Visual Studio code coverage data programmatically.

Additionally, a bunch of analysis fixes went in to improve the code coverage results and the merging of code coverage files.  Unfortunately, the overall code coverage results UI (something I did not own when I owned code coverage) has remained unchanged from the previous version.

That’s it for now.  I hope to blog a little bit more about code coverage before going in-depth into the test impact analysis features of Visual Studio 2010.  Following that, I hope to discuss IntelliTrace since that is my current feature area.

Comments

• Anonymous
  December 01, 2009
  The comment has been removed

• Anonymous
  December 01, 2009
  Hi filotas: I've just published an entry on using the 2010 API that will hopefully help solve your problem.  Note that when passing executable and symbol paths, it's an enumeration of paths now and not a single, semi-colon delimited lsit of paths like it was in 2008, so make sure that "coveragePath" and "symbolPath" in your example above are a single path. If you're unable to get things working after reading my new post, let me know what behavior you're seeing and I'll do what I can to help solve the problem.

• Anonymous
  December 02, 2009
  Great post !!!