WARN: The Code Coverage report doesn't contain any coverage data for the included files

SonarQube Cloud
,
1

I work with a repository that’s a mix of C# and Typescript projects and my team recently started encountering an issue where Sonar is reporting 0% code coverage on any C# changes. Most of the workflow/tooling hasn’t changed in years (including our use of Sonar). The most recent change was converting from the CodeCoverage.exe tool to the dotnet-coverage tool to produce the .coveragexml file for coverage stats, but this change was made March 10 and coverage was still being reported correctly until earlier this week (May 26). I noticed this warning in the logs:

WARN: The Code Coverage report doesn`t contain any coverage data for the included files. Troubleshooting guide: https://community.sonarsource.com/t/37151

I checked the linked troubleshooting guide and noticed that the dotnet-coverage tool isn’t listed under the prerequisites as a supported code coverage tool, but is listed as supported under the dotnet test coverage docs so the first thing I’m hoping to confirm is that the dotnet-coverage tool is supported for code coverage of C# projects.

If so, here’s some additional information about our workflow:

  • GitHub for source control where developers open pull requests against a main trunk
  • Jenkins for the build workflow where the following commands are run to start the sonar analysis, build projects, run tests, and end the sonar analysis
    • Begin sonar analysis
      "C:\Program Files\dotnet\\dotnet.exe" "C:\jenkins\tools\hudson.plugins.sonar.MsBuildSQRunnerInstallation\SonarCloud_for_MSBuild\SonarScanner.MSBuild.dll" begin /o:"camis" /k:"camis" /d:sonar.host.url="https://sonarcloud.io" /d:sonar.login="****" /s:"workspace\SonarQube.Analysis.xml" /v:"5.99"
    • Build the relevant source and test projects (if the actual commands for these are relevant let me know but they’re all just dotnet build commands)
    • Run the tests
      . "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\Common7\IDE\CommonExtensions\Microsoft\TestWindow\\vstest.console.exe" <insert list of dlls here> /Enablecodecoverage /Settings:'workspace\\Process\\Build\\Camis\\JenkinsHelpers\\unit-tests.runsettings' /logger:'trx;LogFileName=UnitTests-NETCoreAppVersionv80.trx' /platform:x64 /InIsolation /Framework:.NETCoreApp,Version=v8.0
    • Generate the coveragexml file for sonar
      dotnet-coverage merge "TestResults\**\*.coverage" --output "TestResults\unit-test.coveragexml" -f xml
    • End sonar analysis
      . "C:\Program Files\dotnet\\dotnet.exe" "C:\jenkins\tools\hudson.plugins.sonar.MsBuildSQRunnerInstallation\SonarCloud_for_MSBuild\SonarScanner.MSBuild.dll" end /d:sonar.login="****"

I’ve attached the .runsettings and SonarQube.Analysis.xml files used in the commands, as well as the full debug logs and TestResults folder from Jenkins (minus the intermediary .coverage binary files). One interesting thing I noticed after enabling verbose logging was an entry about coverage files:
DEBUG: Analyzing coverage after aggregate found '32' coverage files.
Followed by 32 entries of
DEBUG: The file '<example>.cs' is either excluded or outside of your solution folder therefore Code Coverage will not be imported.
where one of the files listed is a file I’d expect to have code coverage statistics for, but most of the files listed weren’t even changed in the PR.
And then immediately followed by

DEBUG: The total number of file count statistics is '32'.
INFO: Coverage Report Statistics: 32 files, 0 main files, 0 main files with coverage, 0 test files, 32 project excluded files, 0 other language files.
WARN: The Code Coverage report doesn`t contain any coverage data for the included files. Troubleshooting guide: https://community.sonarsource.com/t/37151

There are no exclusions listed in the xml file used for analysis, and I don’t believe that file would be covered by any of the exclusion patterns we have configured in the portal:

Excluded sources for coverage: **/AutofacGeneralModule.cs, **/AutofacOrganizationModule.cs, **/Program.cs, **/Startup.cs, **/wwwroot/**, **/Persistence/**, Porter/**, **/Transformer/**, **/bin/**, **/obj/**, **/Connected Services/**, Lib/**, **/android/**, **/ios/**, **/*.xaml.cs, **/*.sql, **/*.html, **/*.resx, Testing/**, Auth/**, Npm/**, **/node_modules/**, **/*.Tests/**, Presentation/Reporting*/**, **/__tests__/**, Prime.Client/build-scripts/**, **/**.stories.**, **/storybook-base/**, **/FakesAssemblies/**, **/Fakes/**, Spirit/Spirit/Content/ContentManagementPageModel.cs

I’m unclear on what “…outside of your solution folder…” means but the commands I shared are being run from the root of the repository, and again, this was all working fine up until earlier this week, so I’m hoping someone can help me identify the issue.
Logs.zip (4.5 MB)
TestResults.zip (17.3 MB)
SonarQube.Analysis.zip (1.1 KB)

2

Hi,

Unfortunately, I can’t read your end step log, but the SonarQube.Analysis.xml is interesting. Did you set these inclusions manually somewher?

 
Ann

3

Hi Ann,

Thanks for your response. I’ve attached a truncated version of the end step that hopefully still contains any relevant information. Please let me know if you still have issues reading it.

To your question about the SonarQube.Analysis.xml file: in our build workflow, prior to the sonar begin command, we run a New-SonarQubeAnalysisFile.ps1 powershell script (I’ve attached a copy) that generates that SonarQube.Analysis.xml file. One of the arguments is the list of files modified in a PR, which the script uses to set the sonar.inclusions property.

Randy

End sonar analysis verbose truncated.txt (32.2 KB)
New-SonarQubeAnalysisFile.txt (6.2 KB)

4

Hi,

Thanks for the log. This jumps out at me:

[2025-05-28T15:57:54.708Z] SonarScanner for MSBuild 5.8

5.8 is from 2022. The current version is 7.3. Can you upgrade and try again?

 
Thx,
Ann

5

Hi Ann,

I can definitely try updating, but would you be able to share where to find version 7.3? I was reviewing the versions under Installing the SonarScanner for .NET | SonarQube Cloud Documentation and don’t see it.

In lieu of that version specifically, I’ll try latest (10.1.2).

Thanks,

Randy

6

Hi Randy,

The download is at the top of that page you linked.

 
HTH,
Ann

7

I’ve run another analysis using the latest version (10.1.2) and attached the truncated logs. The WeatherForecastController class is what I’d expect to have coverage stats for, and I can see logs that suggest the file is being included and indexed, and then an entry similar to something from my original post about how the file is is either excluded or outside of your solution folder therefore Code Coverage will not be imported.

There’s also these info and warning entries about report statistics and coverage:

[2025-06-03T17:32:30.820Z] 13:32:30.742 INFO: Coverage Report Statistics: 31 files, 0 main files, 0 main files with coverage, 0 test files, 31 project excluded files, 0 other language files.
[2025-06-03T17:32:30.820Z] 13:32:30.742 WARN: The Code Coverage report doesn`t contain any coverage data for the included files. Troubleshooting guide: https://community.sonarsource.com/t/37151

where 29 of the 31 files listed didn’t change, but the WeatherForecastController.cs file that I added has a corresponding WeatherForecastControllerTests.cs file that should result in coverage.

I’m assuming the correlation between the number of files listed and report statistics isn’t a coincidence, which means they fall into the “excluded” condition of the either excluded or outside your solution folder. I couldn’t find any documentation on what makes something fall into the “project excluded files” statistic - is there documentation you can share or clarification you can provide around that?

For comparison, I have a log entry from a build on May 23rd (prior to this issue being observed for PRs) of our main branch where the report stats look different in that there’s 0 project excluded files:

[2025-05-23T08:55:52.693Z] INFO: Coverage Report Statistics: 8285 files, 8257 main files, 8257 main files with coverage, 28 test files, 0 project excluded files, 0 other language files.

We run sonar analyses of our main branch nightly, and from what I can tell, May 27 is the first analysis where files started getting excluded. We’re still trying to definitively rule out anything changing with our build/analysis workflow, but I’m also wondering if anything could have changed within the SonarCloud product to have started causing this behaviour?

I appreciate all your time so far,

Randy

End sonar analysis verbose truncated.txt (3.4 MB)

8

Hi,

Thanks for taking the upgrade. That at least eliminates one potential problem point.

Going back to your logs

[2025-06-03T17:32:30.820Z] 13:32:30.667 DEBUG: The file '/C:/Jenkins/workspace/Camis5/Camis5/Testing/Common/FixtureCustomizations/AlternatingGatewaySessionBuilder.cs' is either excluded or outside of your solution folder therefore Code Coverage will not be imported.

I notice this path has Testing in it. I’m wondering if that project is being categorized as a test project. One quick way to know would be to look at these files in the Code tab to see whether they get a source icon or a test icon.

Selection_002
Selection_002834×126 6.67 KB

 
Ann

9

Hi Ann,

There are two different projects listed in the log entries about files being “…either excluded or outside of your solution folder…”: Testing.Common and Prime.Server. The pull request that generated those logs only contains changes to files in the Prime.Server project so I’m not sure why those files from the Testing.Common project are being included.

The analysis details in SonarCloud seem to show the correct categorization of the Prime.Server files:

image
image1146×282 22.4 KB

I’ve reviewed the documentation on projects being categorized as test projects and I don’t believe anything in the project file would meet the criteria, but I’ve explicitly added the <SonarQubeTestProject>false</SonarQubeTestProject> property to see if that has any effect. I’ll post a reply with the results of the PR analysis when it’s complete.

I’m going to take a more thorough look at the nested dependencies, though I don’t know how likely that is as a cause because we have dozens of C# projects in this repository and the coverage issue is affecting all of them as far as I can tell. So any other suggestions you might have based on what I’ve shared so far would be tremendously appreciated.

Thanks again,

Randy

10

Hi,

I didn’t read this post closely enough at the time & jumped straight to the log.

Why are you doing this? I suggest you try without this. A PR analysis should already be limited to what was changed in the PR.

 
Ann

11

Hi Ann,

I’ve tried removing the sonar.inclusions property and no change in behaviour. The file that should have coverage gets listed under the sonar.sources property in the sonar-project.properties file, listed under a Source paths debug log, gets logged as indexed…

[2025-06-05T13:27:19.974Z] 2B7E0AEA-B618-4D47-9F55-3248DFCE1459.sonar.sources=\
...
[2025-06-05T13:27:19.974Z] "C:\\jenkins\\workspace\\Camis5\\Camis5\\Service\\Graph.Sidekick\\WeatherForecastController.cs",\
...
[2025-06-05T13:27:57.487Z] 09:27:56.982 INFO: Indexing files of module 'Service.Graph.Sidekick'
[2025-06-05T13:27:57.487Z] 09:27:56.983 INFO:   Base dir: C:\Jenkins\workspace\Camis5\Camis5\Service\Graph.Sidekick
[2025-06-05T13:27:57.487Z] 09:27:56.983 DEBUG:   Source paths: ..., WeatherForecastController.cs, ....
...
[2025-06-05T13:27:57.488Z] 09:27:57.122 DEBUG: 'Service/Graph.Sidekick/WeatherForecastController.cs' generated metadata with charset 'UTF-8'
[2025-06-05T13:27:57.488Z] 09:27:57.122 DEBUG: 'Service/Graph.Sidekick/WeatherForecastController.cs' indexed with language 'cs'
...
[2025-06-05T13:35:11.683Z] 09:35:11.426 DEBUG: Found indexed file '/C:/Jenkins/workspace/Camis5/Camis5/Service/Graph.Sidekick/WeatherForecastController.cs' for coverage entry '/_/Service/Graph.Sidekick/WeatherForecastController.cs'.

…but then later in the logs gets logged as excluded

[2025-06-05T13:44:21.562Z] 09:44:21.335 DEBUG: The file '/C:/Jenkins/workspace/Camis5/Camis5/Service/Graph.Sidekick/WeatherForecastController.cs' is either excluded or outside of your solution folder therefore Code Coverage will not be imported.

As far as why we’re setting that, I can’t give you a definitive answer. This workflow has existed largely unchanged since 2019, including the bit where we’re setting the sonar.inclusions property, and I haven’t been able to find any changes to the tooling (GitHub repo, Jenkins, Sonar project) that would explain the change in behaviour.

We have other smaller repositories where coverage for .NET projects is still working as expected so I think my next step is to rebuild the workflow for the problematic repo/sonar project from scratch until coverage breaks, unless you have any other suggestions based on the logs/info I’ve provided.

Thanks again for your time,

Randy

12

Hi Randy,

What do the paths in your coverage report look like? Are they relative or absolute? And do they exactly match the paths analysis is seeing?

 
Ann

13

The paths in the coverage report appear to be relative, and they match what’s logged as the “coverage entry” for each file. E.g., the .coveragexml file contains an entry of

<source_file id="8" path="/_/Service/Graph.Sidekick/WeatherForecastController.cs" checksum_type="SHA256" checksum="..." />

which matches the log entry mentioning indexing

[2025-06-05T13:35:11.683Z] 09:35:11.426 DEBUG: Found indexed file '/C:/Jenkins/workspace/Camis5/Camis5/Service/Graph.Sidekick/WeatherForecastController.cs' for coverage entry '/_/Service/Graph.Sidekick/WeatherForecastController.cs'.

but any other mention of that file in the analysis logs appears to use absolute paths.

A colleague of mine noticed that we introduced the following Directory.Build.props file a little over a year ago, in part to obfuscate the paths that get included in exception stack traces:

<Project>
    <!--checks for CI environment variable-->
    <PropertyGroup Condition="'$(CI)' == 'true'">
        <ContinuousIntegrationBuild>true</ContinuousIntegrationBuild>
    </PropertyGroup>
</Project>

Setting that property to true is what results in the C:/Jenkins/workspace/Camis5/Camis5 portion of the file paths being replaced with /_/.
Setting that property to false seems to result in none of the “Found indexed file … for coverage entry …” logs and also results in coverage being reported accurately, which is great, but it’s still unclear why it was working from May 2024 until now.

We also noticed a warning in one of our test runs about module-relative vs project-relative paths when we set the sonar.inclusions property:

Specifying module-relative paths at project level in the property 'sonar.inclusions' is deprecated. To continue matching files like 'Prime/Server/Common/WeatherForecast.cs', update this property so that patterns refer to project-relative paths.

If that file belongs to a project where the csproj file is located at $/Prime/Prime.csproj and the file itself is located at $/Prime/Server/Common/WeatherForecast.cs (where $ is the repository root), what would the supported path specification look like as part of the sonar.inclusions property? Currently our workflow generates something like Server/Common/WeatherForecast.cs; should it actually be Prime/Server/Common/WeatherForecast?

I know you implied we shouldn’t need to use the sonar.inclusions property for pull requests, but in our testing without it, the duration of our analysis stage went from ~15 minutes to ~2 hours so resolving the warning without removing use of the property would be preferable, at least for now.

14

Hi,

I don’t read these paths as matching. Unless there’s supposed to be some Windows magic about _ as a directory that I don’t know about?

 
Ann

15

Hi Ann,

The path listed in the coveragexml file
/_/Service/Graph.Sidekick/WeatherForecastController.cs
matches the path listed as the “coverage entry”
/_/Service/Graph.Sidekick/WeatherForecastController.cs

I was interpreting the the log “Found indexed file … for coverage entry …” as some sort of mapping, i.e., that sonar knows that coverage entry is associated with that file. I take it from your latest reply that I’m mistaken, but I don’t think it was an unreasonable interpretation of the logs. Hopefully at least this thread will keep someone else from making the same mistake.

Regarding the warning about module-relative paths vs project-relative paths I shared in my last reply, we made a change that resulted in the warning not appearing in the logs, but had no effect on the coverage issue, which isn’t necessarily surprising but I thought it was another thing worth mentioning for anyone else reading this thread in the future.

Setting the ContinuousIntegrationBuild flag to false for workflows where we want sonar analysis to happen has resolved our missing coverage issue, so this thread can be considered resolved. Thanks again for your time.

Randy

1 Like
16

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.