Update: 11/30/2012, I added a few more overrides to the automation peer to improve it’s behavior when used with the Narrator screen reader.

Screen Readers

If you’re running Windows 8 (and probably other versions as well), there is a program called Narrator that will convert screen text into spoken words, which allows someone who is blind to use a mouse. It’s pretty amazing technology, and I’m certainly not an expert on it. Supporting this ability is technology known as UI Automation, which provides a way for developers to write programs that can look at the content on the screen. This system uses a provider model, with different sets of providers for different types of applications, including native C++, WPF, Web, and Windows Store applications.

Inspecting the UI

The Windows Software Developers Kit (SDK) for Windows 8 (and a similar one for Windows 7 if I remember correctly) includes a program called Inspect that allows you to see the contents that are on your screen:

Here you can see that I’ve selected UI Automation Mode and Content View from the Options menu. Using these values mimics what a screen reader will see. I used this tool to figure out why my TextBlock controls weren’t being read by Narrator.

Finding the Problem

Here is how I found the problem. First, I selected Raw View in the Options menu. This will show everything, even elements that aren’t accessible to screen readers. I wanted to see what was different between these “hidden” elements and the “visible” ones. After some searching, I discovered the following properties in the right page of Inspect:

I’ve highlighted the property that made a difference: IsControlElement. My next question was “how do I set IsControlElement to true for TextBlock?”

Making TextBlock Accessible

After some searching in Bing, I found some references to overriding the protected OnCreateAutomationPeer method of the TextBlock and returning a new automation peer instance that returns True from it’s IsControlElementCore method.

However, there was a problem: the Windows Store app version of TextBlock is marked sealed, so you can’t subclass it! The full WPF version of TextBlock is not marked sealed. So what can you do?

My solution was to create a new control that I call AccessibleTextBlock that I then use in place of the normal TextBlock control. I scratched my head about how best to do this and made some lucky guesses. In the end, it turned out not to be that hard. First, here is an example of using this new control:

<ctls:AccessibleTextBlock
      Text="{Binding Name}"
      TextStyle="{StaticResource BodyTextStyle}" />

What’s the TextStyle property? It allows you to use styles targeted at TextBlock controls. You can’t apply such styles directly to this new AccessibleTextBlock because it doesn’t, and can’t, inherit from TextBlock. Hence, this property applies the style to the embedded TextBlock control.

Creating the Control Template

The AccessibleTextBlock control is a custom control, which means it has a XAML template you’ll need to add to your main resource dictionary. This template looks like this:

<Style TargetType="ctls:AccessibleTextBlock">
    <Setter Property="Template">
        <Setter.Value>
            <ControlTemplate TargetType="ctls:AccessibleTextBlock">
                <TextBlock x:Name="Container" 
                           Text="{TemplateBinding Text}"
                           TextTrimming="{TemplateBinding TextTrimming}"
                           TextWrapping="{TemplateBinding TextWrapping}"/>
            </ControlTemplate>
        </Setter.Value>
    </Setter>
</Style>

public sealed class AccessibleTextBlock : Control
{
    public AccessibleTextBlock()
    {
        this.DefaultStyleKey = typeof(TextBlock);
    }

    public string Text
    {
        get { return (string)GetValue(TextProperty); }
        set { SetValue(TextProperty, value); }
    }

    public Style TextStyle
    {
        get { return (Style)GetValue(TextStyleProperty); }
        set { SetValue(TextStyleProperty, value); }
    }

    public TextTrimming TextTrimming
    {
        get { return (TextTrimming)GetValue(TextTrimmingProperty); }
        set { SetValue(TextTrimmingProperty, value); }
    }

    public TextWrapping TextWrapping
    {
        get { return (TextWrapping)GetValue(TextWrappingProperty); }
        set { SetValue(TextWrappingProperty, value); }
    }

    public static readonly DependencyProperty TextProperty =
        DependencyProperty.Register("Text", typeof(string), typeof(AccessibleTextBlock), new PropertyMetadata(String.Empty));

    public static readonly DependencyProperty TextWrappingProperty =
        DependencyProperty.Register("TextWrapping", typeof(TextWrapping), typeof(AccessibleTextBlock), new PropertyMetadata(TextWrapping.NoWrap));

    public static readonly DependencyProperty TextTrimmingProperty =
        DependencyProperty.Register("TextTrimming", typeof(TextTrimming), typeof(AccessibleTextBlock), new PropertyMetadata(TextTrimming.None));

    public static readonly DependencyProperty TextStyleProperty =
        DependencyProperty.Register("TextStyle", typeof(Style), typeof(AccessibleTextBlock), new PropertyMetadata(null));

    protected override AutomationPeer OnCreateAutomationPeer()
    {
        return new TextBlockPeer(this);
    }

    protected override void OnApplyTemplate()
    {
        var child = GetTemplateChild("Container") as TextBlock;
        if (child != null && TextStyle != null)
            child.Style = TextStyle;

        base.OnApplyTemplate();
    }

    private class TextBlockPeer : FrameworkElementAutomationPeer
    {
        public TextBlockPeer(FrameworkElement owner)
            : base(owner)
        {
        }

        protected override string GetClassNameCore()
        {
            return "TextBlockAccessable";
        }

        protected override string GetLocalizedControlTypeCore()
        {
            return “text”;
        }

        protected override string GetNameCore()
        {
            return ((AccessibleTextBlock)Owner).Text;
        }

        protected override bool IsControlElementCore()
        {
            return true;
        }

        protected override AutomationControlType GetAutomationControlTypeCore()
        {
            return AutomationControlType.Text;
        }

        protected override IList<AutomationPeer> GetChildrenCore()
        {
            return null;
        }
    }

GetNameCore

Returns the text from the inner TextBlock control as the “Name” property of the control. Screen readers use this value as the text to read.

IsControlElementCore

This method must return true in order for the Narrator application to consider this a readable element.

GetAutomationControlTypeCore

By returning the type Text from this control, we tell the Narrator that this is a text control. For most controls, Narrator reads the text of the control, and then it reads the type of the control. The type is returned by GetLocalizedControlTypeCore. However, for text controls, Narrator only reads the text of the control and bypasses saying “text.” This override makes the AccessibleTextBlock control behave the same way.

GetChildreCore

Without overriding this method, applications like Inspect will show the child TextBlock. Returning null from this overridden method ensures that Inspect shows the AccessibleTextBlock as having no children, which makes it look more like a TextBlock control

When you right-click an item (or swipe down with touch), the item is selected (MSFT here) and the app bar pops up with commands that apply to this item. For whatever reason, I had a hard time finding an example of how to handle all these details. In the end, it turned out to be very simple—you just have to change several settings and add a little code. However, it took me some trial and error to get this to work.

Setup the GridView Control

The first step is to allow selection with the GridView control, which is disabled by default. You can enable selection with the following code:

<GridView
    x:Name="itemGridView"
    AutomationProperties.AutomationId="ItemGridView"
    AutomationProperties.Name="Grouped Items"
    Grid.RowSpan="2"
    Padding="116,137,40,46"
    ItemsSource="{Binding Source={StaticResource groupedItemsViewSource}}"
    ItemTemplate="{StaticResource Standard250x250ItemTemplate}"
    SelectionMode="Multiple"
    IsSwipeEnabled="True"
    IsItemClickEnabled="True"
    ItemClick="ItemView_ItemClick" SelectionChanged="itemGridView_SelectionChanged">

I’ve changed two properties: SelectionMode and IsSwipeEnabled from what I got with the template for an Items Page. Setting SelectionMode to Multiple ensures several things. First, no items are initially selected, as they would be with single selection. Second, you can use the keyboard to move between item and then the space bar to select an item, which is the behavior that you’ll find in the Finance application.

You’ll also need to set IsSwipeEnabled to True to allow swiping down with your finger to select an item.

Finally, we need to receive the SelectionChanged event so our code can display the app bar whenever an item becomes selected.

Showing the App Bar

We want to display the app bar whenever an item becomes selected, whether from the keyboard (with space bar), the moue (right click), or swiping down with your finger:

private void itemGridView_SelectionChanged(object sender, SelectionChangedEventArgs e)
{
    if (itemGridView.SelectedItem != null)
        BottomAppBar.IsOpen = true;
}

There is one final detail—when the app bar closes, you want to unselect any items. First, register to receive the Closed event for your app bar in your page’s constructor:

this.InitializeComponent();
BottomAppBar.Closed += BottomAppBar_Closed;

Finally, here is the code to handle the closed event:

private void BottomAppBar_Closed(object sender, object e)
{
    itemGridView.SelectedItem = null;
}

With these small changes, you can add commands to the app bar to operate on items in your page.

Allowing Multiple Selections

Without much more work, you can allow multiple selection. In this case,  you can continue to select more items while the app bar is open. Supporting this requires a couple of small changes. First, you’ll want to change the app bar to be sticky, which you can do by adding the following to your page’s constructor:

BottomAppBar.IsSticky = true;

This turns off the automatic closing of the app bar when you tap or click outside of the app bar.

Next, you’ll want to show the app bar as long as there are items selected, and hide it when there are no items selected. Change the code in your SelectionChanged event handler to read like this:

private void itemGridView_SelectionChanged(object sender, SelectionChangedEventArgs e)
{
    BottomAppBar.IsOpen = itemGridView.SelectedItems.Count > 0;
}

Now you can right click (or swipe down) to select an item, at which point the app bar appears. While the app bar is visible, you can right-click or swipe down to select more items.

Dismissing The App Bar

There are a couple more things to finish up the experience. When the app bar is visible, you can dismiss the app bar by left clicking (tapping) anywhere outside the app bar, or you can press the escape key. Here is the code you’ll need to handle those situations:

protected override void OnTapped(TappedRoutedEventArgs e)
{
    base.OnTapped(e);
    BottomAppBar.IsOpen = false;
}

protected override void OnKeyUp(KeyRoutedEventArgs e)
{
    base.OnKeyUp(e);
    if (e.Key == VirtualKey.Escape)
        BottomAppBar.IsOpen = false;
}

The solution involves adding a custom data- attribute to each item in the list, creating CSS entries for hover and selected, and writing a single jQuery method that handles updating the section. In the example below, I’m using data-query on HTML elements, like this:

@foreach (Query query in Model)
{
    <div data-query="@query.Key">@query.Name</div>
}

CSS Class

Next I added some CSS to display different colors for hover and selected:

div[data-query]:hover
{
    background-color: #EEF;
    cursor: pointer;
}

.querySelected
{
    background-color: #CCF;
}

The first entry changes the color and mouse pointer for the entry under the mouse. It does this by selecting all div elements that contain the data-query attribute. The second entry is simply a class that we’ll apply to the “selected” element using some jQuery code.

jQuery Code

The following jQuery code is all that you need:

$("[data-query]").click(function () {
    $("[data-query]").removeClass("querySelected");
    $(this).addClass("querySelected");
    // Do any work on the selected element
});

The first line removes the querySelected class from any elements that have the data-query attribute. This basically removes the highlighting from all elements in the list. The second line adds the querySelected class only to the element that received the click, basically highlighting that element.

In the rest of the click function, you can add other operations you might want to perform when you click on a list item.

As a result, I started naming my tests with names like this, using underscores to separate the different BDD keywords:

[TestMethod]
[Description("Column order is different, but tables match")]
public void ShouldNotThrow_WhenAreEqual_GivenSameData_ButColumnOrderDifferent()

This worked reasonably well in Visual Studio 2010 tests results window because I could show the Description column. That way the test results included an easy to read description (the Description attribute), as well as the Given/When/Then behind the test (although I put the Then part first and called it Should):

Then along came Dev11 beta. They’ve completely changed the test results experience. The new version, at least in the beta, doesn’t support the description attribute, so you only see the test method names, resulting in my test results looking like this:

Argh! That makes it really hard to read test methods. Plus, I wasn’t completely happy with the long test methods anyway. What to do?

Rethinking Test Method Naming

I had a nice conversation with another former p&p colleague, Peter Provost, who is a PM working on the test experience. He suggested that I put the BDD description into the Description attribute. I decided to try this out, and so far I’m liking the change:

// Column order is different, but tables match
[TestMethod]
[Description("Given two tables And same data But different column order | When TableAssert | Then true")]
public void ColumnOrderDoesntMatter()

One nice thing about this approach is that the BDD description is easier to read and it can be richer without overwhelming the method name.

Wishful Thinking

I think it would be really cool (just my opinion) if this had a rich tooltip that showed the class information (the current tooltop does) and also the Description attribute. It would also be really cool if I could write an VS extension that would format my descriptions into multiple lines with keywords like Given, When, and Then in bold. Hint, hint VS guys…

In this blog post I’ll show you a very fast way to retrieve a tree of results. Let’s start with the query I’m using:

SELECT [System.Id], 
       [System.Title], 
       [Microsoft.VSTS.Common.BacklogPriority], 
       [System.AssignedTo], 
       [System.State, 
       [Microsoft.VSTS.Scheduling.RemainingWork], 
       [Microsoft.VSTS.CMMI.Blocked], 
       [System.WorkItemType] 
  FROM WorkItemLinks 
 WHERE (
        Source.[System.TeamProject] = @project 
    AND Source.[System.WorkItemType] IN ('Product Backlog Item', 'Bug')
    AND (
        Source.[System.State] <> 'Removed' 
        AND Source.[System.State] <> @closedState
      )
    )
    AND [System.Links.LinkType] = 'System.LinkTypes.Hierarchy-Forward'
    AND Target.[System.WorkItemType] <> ''
ORDER BY [Microsoft.VSTS.Common.StackRank], [Microsoft.VSTS.Common.Priority], [System.Id] mode(Recursive)

I’ve highlighted the FROM location, which in this case is WorkItemLinks, which you need to use in order to retrieve a hierarchy. Flat querys pull from WorkItems.

Retrieving a tree of work items actually takes two queries. The first query returns a list of work item IDs that contains SourceId and TargetId values (parent and child IDs when the link type is Hierarchy-Forward as here). However, the query does not return any of the details of the work item. For that you’ll need a second query (described later).

The tree query above also contains two parameters (@project and @closedState) that will need values. Here is a code snippet that shows supplying values and retrieving the list of IDs:

Dictionary<string, object> parameters = new Dictionary<string, object>();
parameters.Add("project", _tfsProjectName);
parameters.Add("closedState", "Done");

var treeQuery = new Query(_workItemStore, wiql, parameters);
WorkItemLinkInfo[] links = treeQuery.RunLinkQuery();

The first part of the code creates a dictionary with the parameter values to use when running the query. You must use the RunLinkQuery method to run the query, instead of the RunQuery method, when working with WorkItemLinks. Calling RunQuery when you reference WorkItemLinks will throw an exception.

The links array returned from this query might look something like this:

These results represent a tree. In our case the tree has just one level of children. As an example, work item 23268 is the parent of two other work items: 23339 and 23464. However, more importantly, the results of running this query do not return any of the fields from the query. How do you get those fields? You have to run another query that returns the results. The second query needs to use the set of columns from the original query, but pull from the WorkItems “table” instead of WorkItemLinks.

//
// Build the list of work items for which we want to retrieve more information
//
int[] ids = (from WorkItemLinkInfo info in links
             select info.TargetId).ToArray();

//
// Next we want to create a new query that will retrieve all the column values from the original query, for
// each of the work item IDs returned by the original query.
//
var detailsWiql = new StringBuilder();
detailsWiql.AppendLine("SELECT");
bool first = true;

foreach (FieldDefinition field in treeQuery.DisplayFieldList)
{
    detailsWiql.Append("    ");
    if (!first)
        detailsWiql.Append(",");
    detailsWiql.AppendLine("[" + field.ReferenceName + "]");
    first = false;
}
detailsWiql.AppendLine("FROM WorkItems");

//
// Get the work item details
//
var flatQuery = new Query(_workItemStore, detailsWiql.ToString(), ids);
WorkItemCollection details = flatQuery.RunQuery();

Here is what this code does:

• Create an array of work item ids in the same order as returned by the tree query
• Build a new query that has this form: “SELECT {field list} FROM WorkItems”. The Query instance used to retrieve the tree of work item IDs has a property called DisplayFieldList that contains the the list of fields contained in the query. The code uses this list to build a new flat query that returns all the fields from the original tree query.
• Call the RunQuery method on the new flat query

The set of work items returned by this new query will be in exactly the same order as the link query results at the top of this post. You can then “combine” these two results sets to build a tree and use this tree as you need.

Using this approach is very fast because there are just two queries. I don’t have any inside knowledge about how the TFS client using the SDK to retrieve results, but I wouldn’t be surprised if it’s very much like what I’ve outlined here.

I thought the answer was “no,” until someone suggested MUI. My first reaction was “what’s that?” MUI, as it turns out, stands for Multilingual User Interface and has been supported in one way or another since Windows XP. I did not know this. The idea is that you remove the resources from your main binaries and instead put them into MUI files, which are just DLLs with a different extension. For example:

MyApplication.exe  <— No resources
en-US
    MyApplication.exe.mui  <— Language-neutral (in this case English)
de
    MyApplication.exe.mui  <— German
   

In the picture above, the first MUI file (under the en-US directory) contains the English resources (strings, dialog boxes, etc.). This MUI file is marked as both the en-US file and the language-neutral file that will be used when Windows can’t find a better match.

The second MUI (under the de directory) contains the German resources that will be used whenever the Windows’ current language is German (weather that be in Germany, or any other country).

With very little work (less than a day), we were able to build a version of our application that our customers can translate to their heart’s content. Below I describe the steps for a developer to make their application translatable after the fact.

Before you Start

In order to create an MUI-aware application, you’ll need to install the Windows 7 SDK, which is where you’ll find MUIRCT.

Creating the MUI Files

You may not need to make many changes in your application to make all of this work if you only support Vista or later. If you require Windows XP support, you’ll need to read the section below.

The first step is to run a program called MUIRCT that will move the resources from your main executables into satellite executables. This program requires a config file that describes which resources to move over. Here is the file I used:

<?xml version="1.0" encoding="utf-8"?> 
<localization>
  <resources>
    <win32Resources fileType="Application">
      <neutralResources>
        <resourceType typeNameId="#16" />
      </neutralResources>
      <localizedResources> 
         <resourceType typeNameId="#2" />
         <resourceType typeNameId="#3" />
         <resourceType typeNameId="#4" />
         <resourceType typeNameId="#5" />
         <resourceType typeNameId="#6" />
         <resourceType typeNameId="#9" />
         <resourceType typeNameId="#11" />
         <resourceType typeNameId="#16" />
      </localizedResources> 
    </win32Resources>
  </resources>
</localization>

For more details, read Preparing a Resource Configuration File on MSDN.

Next you’ll need to run MUIRCT to split your files:

muirct.exe -q muiconfig.xml -v 1 -x 0x0409  ..\MyApplication.exe MyApplication.exe en-US\MyApplication.exe.mui

The “..\MyApplication” refers to the original EXE that contains all the language-neutral resources (the 0x409 says they’re en-US resources). The second-to-last parameter, “MyApplication.exe” is the name that will be used for the new version that contains none of the resources being moved. Finally, the last parameter contains the name of the MUI file that will be created to contain all the resources that are called out in the config file as resource you want to move.

If you have no need to support Windows XP, you’re done.

Supporting Windows XP

Windows Vista and later automatically handle locating and using the correct MUI file for resources. However, if your application needs to be able to run on Windows XP as well, you’ll need to make some changes to your code. In our case that was really easy because the calls to load strings were all encapsulated in a helper class. The idea is that you’ll need to call a new API that will located and load the best-match MUI file:

std::vector<WCHAR> moduleName(MAX_PATH);

GetModuleFileName(hModule, &moduleName[0], moduleName.size());
hInstance = ::LoadMUILibrary(moduleName.data(), MUI_LANGUAGE_NAME, 0);

The first two lines get the name of the executable that we’re running. The last line is where the magic happens. LoadMUILibrary is a function that in Windows XP will locate the appropriate satellite MUI file, load that file, and return an instance handle to that file. In Windows Vista and later, this call returns the instance handle for your main executable because the system automatically handles resource location in calls like LoadString.

Additionally, you’ll need to ensure you link to muiload.lib. I like to use a pragma in my source files, rather than setup additional libraries in the link options, using a line like this:

#pragma comment(lib, "muiload.lib")

Localizing MUI Files

I’m not an expert on localization, so I’m not sure what most companies use to localize native Windows applications. Here at Microsoft we use a tool called LocStudio, and I understand there are similar programs available outside of Microsoft.

Whichever tool you use, here’s what you have to do:

• Create a new directory for the new locale using the two-letter language identifier (like “de” for German)
• Copy the language-neutral MUI file
• Translate the strings (and possibly change control sizes and positions in dialogs)
• Copy the localized MUI file into the new directory (“de” in this example)

Just a quick note about Visual Studio. You can open native Windows executable files and edit the resources in them with Visual Studio. However, you cannot save changes you make to MUI files, so you’ll have to use another tool. Again, I don’t have knowledge of those other tools.

Working with Signed Binaries

What happens if the original binaries and MUI files are code signed? It just works. I didn’t know the answer to this so I tested it. I used MUIRCT to split the files, and then code-signed both the main executable and the MUI file. Then I made a localized copy of the MUI file for German that was not signed. I was able to run this and see the English strings when I ran with English as the default language for Windows. When I switched to German and ran the program again, it showed the German strings from the un-signed German MUI files.

However, if you’re running your tests on a 64-bit operating system, chances are you’ll see the test results (pass/fail), but you won’t see any code coverage results. Why not? And how do you fix it?

By default, the test runner in Visual Studio (and on the TFS build server) run as a 32-bit process, which also means that the code coverage tools are the 32-bit versions. When you run unit tests, the test runner loads all the assemblies into the test runner’s process, which means that .NET assemblies will be run as 32-bit assemblies.

The problem occurs when you used coded UI tests. In this case, the executable assembly is not loaded into the test runners process. Instead, it’s launched in a new process. If you assembly is marked as Any CPU, and you running on a 64-bit OS, the application you’re testing will now be a 64-bit application, which means the 32-bit code coverage code won’t be able to capture any code coverage for your code UI tests.

How do you fix this? Basically you want to make sure the builds used for test runs have the EXE targeted for 32-bit rather than Any CPU. One way is to modify the solution so it builds targets the main EXE to 32-bit, as shown here (this is the Configuration Manager dialog for the solution):

The other option is to change the target platform in the build definition

Using either approach will force the assembly that you want to test to be built for the 32-bit platform.

Before:
After:

The arrow on the right is 80% of the original size.

So how did I accomplish this? It turned out to be far simpler than any of the blog posts I found on the subject. They all suggested using Expression Blend to copy the full template and them modify it. But you can use a RenderTransform to reduce the size:

<Expander Header="{Binding Name}" FontSize="16">
    <Expander.RenderTransform>
        <ScaleTransform ScaleX=".8" ScaleY=".8" />
    </Expander.RenderTransform>
</Expander>

Notice that I bumped the font size up to 16. When multiplied by .8, this gives a final font size of 12.8, which is a nice size.

Fixing Delay Signing in SP1

I used the /DELAYSIGN and /KEYFILE settings in the properties page for my C++/CLI project and everything compiled just fine. However, when I tried to use an object from this DLL, I got this message::

CS1577: Assembly generation failed … does not have a strong name

This certainly wasn’t what I expected. My first step was to double-check the signing on the assembly. I used the following command-line command to check:

sn -T AssemblyName.dll

When I ran this command, it reported “AssemblyName.dll does not represent a strongly named assembly". Obviously the properties I set in the project settings dialog weren’t working. After quite a bit of searching, I found a blog post by Amit Mohindra that explained the problem, which is a change in Visual Studio 2010 SP1.

The blog post had suggestions on how to fix the problem, but it seemed like quite a bit of work. I tried another approach, which worked just fine.

Signing via AssemblyInfo.cpp

I added an new file called AssemblyInfo.cpp to my project, which has the following contents:

#include "stdafx.h"
 

using namespace System;
using namespace System::Reflection;
 

[assembly:AssemblyKeyFile("myKey.snk")];
[assembly:AssemblyDelaySign(true)];

This took care of signing the assembly, which I verified using the sn command.

Dealing with C++/CLI vs C# Assemblies

One this was all working, we added a call from our C# EXE into the C++/CLI assembly, and got this run-time error:

Could not load file or assembly 'AssemblyName, Version=0.0.0.0, Culture=neutral, PublicKeyToken=…' or one of its dependencies. An attempt was made to load a program with an incorrect format.

Incorrect format? Huh?

With a little more searching, I found the problem, and now that I understand the problem, it makes perfect sense. First, the solution. You need to change the Platform from Any CPU to x86 for you main EXE (or x64 if you’re building a 64-bit version) to match the bitness of your C++/CLI assembly:

Here’s why we had to make this change. Our C++/CLI assembly is calling not a pure .NET assembly since it’s making calls to windows APIs. As such, the C++/CLI assembly needs to be either 32- or 64-bit. It can’t be both because of the native C++ code it contains. A .NET assembly that is built for Any CPU can run as either a 32- or 64-bit process, but you can’t load a 32-bit DLL into a 64-bit process, hence the error. Building a 32-bit .NET EXE that loads the 32-bit C++/CLI DLL fixes the problem.

There are several issues that make C++ code coverage data “noisy” and/or inaccurate. First, if you use the standard C++ libraries, you’ll find the code coverage results littered with entries from the std namespace, which represents classes and methods provided by Microsoft. Clearly, you don’t want library classes provided by Microsoft to impact your code coverage results. Especially if it lowers your numbers.

Another issue has to do with using template classes. Look at this example, which is a real example from some of our code:

You would probably expect this to show 100% code coverage in Visual Studio (or TFS). It doesn’t. In fact, it reports 72% code coverage. The problem is the return statement at the end. Visual Studio reports code coverage in terms of blocks covered/not covered (also this article). There are blocks in the wstring class that aren’t being covered in this method.

How do you fix this problem?

Building a Code Coverage Report

There are probably many ways to provide better code coverage numbers for C++ code. I chose to write a report for TFS that reads results from the data warehouse and process them to produce more “useful” results. Here is an overview of what the report does with the data (I’ll describe each in more detail):

• Use lines instead of blocks for coverage information
• Treat partially covered lines as covered
• Collapse concrete template instances into a “common” instance
• Use the method results with the highest coverage
• Filter out namespaces and functions

The following sections describe each of these bullets in more detail.

Use lines instead of blocks, and treat partially covered as covered

I debated a long time before making these changes. Visual Studio reports code coverage results based on block coverage, so I wasn’t sure how people would react to using lines instead. However, switching to lines and also treating partially covered lines as covered mitigates the issue I described above. It does mean we’re over-reporting coverage for lines that have conditional code, but our style guidelines call for using multiple lines in such cases, so this is probably a small issue.

Alternatively, there are Visual Studio APIs, found in the Microsoft.VisualStudio.Coverage.Analysis namespace that could be used to process the code coverage results. I haven’t tried this, and it would have taken more time than writing a report.

Collapse template instances

We have some template classes that we use as base classes. The methods are well covered with unit tests. However not all concrete instances call the base methods, and we have a number of concrete instances of these classes. The result is that we get partial code coverage multiplied by the number of concrete instances. Our desire is to know how much coverage we achieve for the code we wrote, not for compiler-generated code. As such, I chose to collapse concrete instances. For example, we have a template called BaseControl, with a concrete instance called BaseControl<ItreeView>. In the report, I collapse this into BaseControl__ so that we can “combine” the results for each base method from sub classes. This brings us to the next topic.

Use the highest coverage results

We have several different runs on our build server, and we want to combine these in the report results. For example, we have unit tests run during gated check-ins, and we runs all our automated acceptance tests nightly. The acceptance tests cover some code (such as UI code) that isn’t covered by the unit tests, and visa versa.

Because of the testing approach we’re using, the unit tests are written in C++/CLI and include the product code directly into the test DLL (see Writing Unit Tests in Visual Studio for Native C++) whereas our acceptance tests are written in C# and use the production DLL. This results in the DLL names being different between these two runs. The report I created replaces these different names with a common name so the data can be combine.

One the report collapses template instances and combined results from DLLs with different names, but representing the same code, there may be more than one record (result) for each method in the product code. How do you combine these records? TFS stores the name of the class and method, as well as lines covered, not covered, and partially covered (and also block information). I chose to use the record for each method that has the highest coverage. So if you have different test runs that cover different parts of a method, choosing the result with the highest coverage will under-report code coverage since there’s no way to tell how much overlap there is between different result records.

Filter out namespaces and functions

In my MSDN article, Agile C++ Development and Testing with Visual Studio and TFS, I talked about filtering out common patterns, such as “std::”, from the results because this represents library code that we don’t want to include. Since then, I’ve found even more patterns, so the new report I created excludes a much larger list.

Using the Results

The results of all this work were very significant. Switching from block to line coverage moved our code coverage results up from 62% for one DLL to about 70%. Doing all the other work took this number up to 87%, which is more of what I expected to see since we used TDD to write all the code in that DLL.

Using the Report

If you’ve never added a new report to your reporting site, you can find some instructions here: http://blogs.msdn.com/b/aaronbjork/archive/2010/07/30/microsoft-visual-studio-scrum-1-0-updated-sprint-burndown-report.aspx.

Code Coverage.rdl

Once you install the report in your team project, you’ll see something that looks like this:

Customizing the Report

There are several places where you can customize the report. Open the report in Report Manager (right click on the Reports node in Team Explorer inside Visual Studio and select Show Report Site), click the Properties tab, then click Parameters. You’ll see something like this:

There are several hidden parameters you can use to provide more control over what you see in the report:

Remember to click Apply to save changes you make to these parameters.