[ExcludeFromCodeCoverage] ignored when using top level statements and partial Program

[im-aIex]

Description

Similar to #5660, when using [ExcludeFromCodeCoverage] on a partial Program class with top level statements the code is not excluded from Code Coverage, even though the coverage report itself does not contain the class/lines.

Repro steps

Console.Write("Hello World");

[ExcludeFromCodeCoverage]
public partial class Program { }

Expected behavior

Lines are excluded from code coverage metrics.

Actual behavior

Lines are included in code coverage metrics.

Known workarounds

Remove top level statements

[ExcludeFromCodeCoverage]
public class Program 
{
    public static void Main(string[] args)
    {
        Console.Write("Hello World");
    }
}

Related information

• C#/VB.NET Plugins version - Azure Devops Analyzer 6.2.0
• MSBuild / dotnet version - net8.0
• SonarScanner for .NET version (if used) - SonarAnalyzer.CSharp 9.30.0.95878

[im-aIex]

In doing further workaround troubleshooting, removing [ExcludeFromCodeCoverage] and including <ExcludeByFile>**/Program.cs</ExcludeByFile> within the .runsettings is also ignored.

All the documentation points to SonarQube just using the reports generated for coverage, which seems to be the case when using the CLI scanner, but the MSBuild scanner appears to be calculating its own "lines to cover" that does not appear to follow many conventions used to control dotnet coverage.

[sebastien-marichal]

Hello @im-aIex,

Thank you for reporting this issue.

I was able to reproduce this issue. I will add it to our backlog so we can fix it in the future. When calculating the executable line of code, we don't consider that global statements could be part of a class with the ExcludeFromCodeCoverage attribute.

... the MSBuild scanner appears to be calculating its own "lines to cover" that does not appear to follow many conventions used to control dotnet coverage.

Could you point out which conventions you are talking about?

Thank you,

[im-aIex]

Both [ExcludeFromCodeCoverage] and utilizing .runsettings are common ways of controlling coverage analysis within dotnet. These are accounted for in the report that is generated and sent to SonarQube, so - based on the documentation - the expectation is that SonarQube would also account for it. Instead, it appears the MSBuild scanner is calculating its own "lines to cover" that is prone to differ from the report.

.runsettings seems like a larger issue in that we can have complex rules configured that would need to be mirrored in the sonar properties.