Excluded Files listed in coverage report

[sixeyes]

I'm currently instrumenting my code using:

AltCover.exe -a ExcludeFromCodeCoverageAttribute ......

While this excludes all the marked code from the coverage statistics, the files with these attributes are included in the report making it more cluttered than I would like.

Am I missing an option somewhere that would remove files with no coverable lines?

[SteveGilham]

I'm not sure what you mean by "the files with these attributes". Which files would those be?

If a type or method is excluded by attribute (or by name), then there will be an empty entry, with a skippedDueTo="Filter" attribute affirming that fact, in the XML document, along with all the vestigial compiler generated entries that seem to comprise much of any report file.

If you want to strip the skippedDueTo="Filter" entries from the XML, it's simplest done in a few lines of PowerShell

$x = [xml](Get-Content .\coverage.xml) 
$x.CoverageSession.Modules.Module.Classes.Class.Methods.Method | ? { $_.skippedDueTo } | % { $_.ParentNode.RemoveChild($_) }
$x.CoverageSession.Modules.Module.Classes.Class | ? { $_.skippedDueTo } | % { $_.ParentNode.RemoveChild($_) }

[sixeyes]

Sorry for the delay in replying but I got diverted onto another project.

I'm sorry but I confused my repository classes and their interfaces. The interfaces are being reported in the code coverage but greyed out. I was hoping to remove them from the report.

Having realised my mistake I tried adding -f I*.cs but that resulted in no code coverage at all.

Any advice would be welcome.

[SteveGilham]

By "greyed out" I'm assuming you mean in a ReportGenerator output, like the line for AltCover.Abstract here (this being a class containing only interfaces as inner types)

which clicks through to a page saying "No files found."

That's how ReportGenerator reacts to a type being named in the coverage file, but containing no source locations. That can either be for a type, like an interface, which contains no executable code (so will also not be affected by any --fileFilter values), or for a type that has been excluded by filter, because that's how the original OpenCover format represents this.

What you are looking for is to have these types completely stripped from the XML.

That sort of thing could be done as an enhancement, provided "these types" can be suitably precisely specified; but the equivalent is more easily done (and more easily tuned to an individual's requirements) via a scripting step between coverage gathering and ReportGenerator processis, e.g.

$x = [xml](Get-Content .\coverage.xml) 
$x.CoverageSession.Modules.Module.Classes.Class | ? { -not $_. Methods.Method } | % { $_.ParentNode.RemoveChild($_) }
$x.Save(".\strippedCoverage.xml")

which removes all types (like interfaces, or classes excluded by filter) that have no method records. Leaving the filtered classes, while removing the obvious interfaces, is left as an easy exercise for the student.

Or you may want to strip out every type without identifiable source location

$x = [xml](Get-Content .\coverage.xml) 
$x.CoverageSession.Modules.Module.Classes.Class | ? { -not $_. Methods.Method.FileRef } | % { $_.ParentNode.RemoveChild($_) }
$x.Save(".\strippedCoverage.xml")

which is a larger set still.

[sixeyes]

In my project, it's the interfaces that are showing up greyed out, not classes. The exclude filters seem to be doing their job (the repository classes have gone). However their interfaces remain.
Running OpenCover on the same project does not result in the interfaces in the report.
I wasn't aware that interfaces could be "covered", so I'm just trying to remove them from the report. In our coding style we have an interface for most classes, so the report is "cluttered" with unwanted rows.

[SteveGilham]

OK, I'm on that, now the requirements are firm.

[sixeyes]

I'm sorry that I've been so unclear.

[SteveGilham]

Could you give the 7.1.782 release a go?

[sixeyes]

That's perfect. Thanks very much.