4

I've written a program that tells me whether all the dlls in a code coverage result file are above a specified code coverage percentage.

It works great except when a dll has 0% code coverage, because dlls with 0% code coverage aren't included in the visual studio code coverage result file at all.

I have access to a list of the dlls that were instrumented for this code coverage run, but I'd much rather just look at the code coverage file if I can.

Is there some way to get Visual Studio to add the code coverage results for dlls where the code coverage percentage = 0%?

user467384
  • 1,137
  • 4
  • 22
  • 38

2 Answers2

4

Full disclosure: I am on the team that develops this feature.

Unfortunately, this information is not present in the code coverage file. When a binary is instrumented, we insert special probes to tell us that it exists and to detect when each code block is executed.

We do not save the list of DLLs in the target process, so we only know about instrumented DLLs that get executed (just being instrumented is not enough).

The easiest workaround is what you mentioned in your question.

Thanks for your feedback, though, we will take it into consideration. Sorry for the difficulty here.

Chris Schmich
  • 29,128
  • 5
  • 77
  • 94
  • Thanks for a definitive answer. It's a pretty unusual request so I'm not terribly surprised. – user467384 Nov 09 '10 at 22:09
  • We don't find it so unusual, it happens quite often that a project reports 90% coverage, but forgot to add 8 projects to the testsettings files causing the reports to be all skewed. – jessehouwing Feb 29 '12 at 20:21
  • Hey @Chris please take a look: http://stackoverflow.com/questions/24767377/visual-studio-2013-code-coverage-binaries-not-being-instrumented. I spent tens of hours trying to figure out why it happens. Of course [this](http://blogs.msdn.com/b/allendm/archive/2012/06/05/troubleshooting-missing-data-in-code-coverage-results.aspx) doesn't help – abatishchev Jul 15 '14 at 20:20
0

The trick we're using is to add one Test Project with a special Test which calls a special public static method in every assembly that does nothing more than return true. That way the assembly is hit at least once and the one liner doesn't really impact the total coverage data.

I've used Reflection to do this in some projects, and now we're just adding the CodeCoverageTest project to every solution and the CodeCoverage.Ensure() method in every Assembly.

jessehouwing
  • 106,458
  • 22
  • 256
  • 341