However a standalone profile is available to download from Microsoft site. Code coverage is vsperfcmd.exe great help for programmer’s confidence on the code. Our project utilizes a different process, which can’t be managed entirely with GUI.

To begin with, we manage our unit tests with boost. In large projects we have hundreds of test files, and managing them through GUI interface is quite formidable. Another issue is the frustration with displaying metrics. The interface provided is quite clunky, and you have to navigate thousands of functions and class methods in order to find coverage for the method you are focusing.

The color display in the editor has a lot for improvement. I recently investigated possibilities to collect and analyze code coverage data programmatically. I noticed that the documentation on this aspect is quite weak, so I’d like to share some points with readers. Collecting Data In order for the code coverage to be collected, the executable must be instrumented. PROFILE is required, while others not mentioning this requirement. In our build system, this link flag triggers the instrumentation. The build system we are using is boost.

It is recommended to add this path into PATH variable in vcvars. PROFILE is found, the executable will be instrumented. Now the second step is to collect data. To collect data you first start vsperfmon process.

Here we use start  command to open a separate console, because execution will block the current console. Code coverage data will be collected. After this command is carried out, the coverage data is stored in the file we specified. The coverage file is in a proprietary format with no documentation about its structure. Fortunately, MS allows us to export using Visual Studio or calling code analysis API. Converting to XML You can drop the coverage file newly created into Visual Studio.

You can not do much with its interface, as you have to navigate many functions to locate the ones you wanted to view. Furthermore, it does not code coverage ratio on source file basis, but rather on method basis. You can export the XML file from Visual Studio, or use the code I provided below to export programmatically. I spent a quite a bit time to convert it into a UTF-8 with line endings so that my favorite editor can open it. The programmatic way that Microsoft wants us to use is through assembly.

I found contain two errors: it failed to point out that symbol path must be set, and the WriteXML call was wrong. I had to overcome some issues not mentioned elsewhere. You must add reference to two files: Microsoft. When I first ran the code, it complained that the assembly does not match the one requested, and I found that the file Microsoft.