SonarQube was deployed using a zip file and extracing it on the Linux machine
Trying to achieve correct coverage report from Sonar, as currently for example if I create a certain function and then a unit test for it - Sonar still says that I have 0% coverage, that is since I upgraded to 2025.1, after using a very old version for a while.
I tried analyzing the logs to find out what could be the case, thing is I found in the logs some warnings about Invalid character encoding (That I use UTF-8 and the encoding there is windows-1252) - BUT, it’s not in the same file that I was editting where Sonar did not recognize the unit test that I created for my code.
So for example I added the following under the file PolicyAttributeHelper.cs**:**
public bool TestingSonar()
{
return false;
}
And then at PolicyAttributeHelperTests.cs, I added:
[Fact]
public void GivenPolicyAttributeHelper_WhenAccessingTestingSonar_ThenReturnsFalse()
{
var result = \_helper.TestingSonar();
Assert.False(result);
}
But yet, Sonar has said I have no coverage for my new code. How come this could happen? The logs are about 5k lines long so I’m not sure if I can copy paste them to here, so I’ll just copy the warning I mentioned earlier as I don’t find any error or other interesting warnings in the log:
2025-09-17T13:46:05.0098456Z WARN: Encoding detected by Roslyn and encoding used by SonarQube do not match for file PdfType0Font.cs. SonarQube encoding is 'UTF-8', Roslyn encoding is 'windows-1252'. File will be skipped.
2025-09-17T13:46:05.0214334Z WARN: Invalid character encountered in file PdfLinkAnnotation.cs at line 168 for encoding UTF-8. Please fix file content or configure the encoding to be used using property 'sonar.sourceEncoding'.
We use C#, .NET Framework v4.7.2 for this specific project for example, will appreciate any guiding or help as for why such a thing could happen, thanks alot!
please give us the verbose output of the scanner commands (please run SonarScanner.MSBuild.exe begin /k:“MyProject” /d:sonar.verbose=true as the begin step, and please attach the output of the BEGIN and END steps)
please give the output of running MSBuild in verbose mode (/v:d)
Also, please tell us:
what are the commands you are running to do the analysis?
are you running all commands from the same folder?
I am now running with verbose=true and i will be able to upload the log file (if it’s possible to send it in private it would even be better of course), thanks again!
It’s also worth noting that Sonar was working great before I upgraded from version 9.7 to 2025.1, and the SonarScanner for MSBuild is version 10.3
Edit: Adding the analyze log file after censoring a few things, it should be with verbose = true, hopefully it can be helpful somehow.. I created a pull request with just a new small boolean function and a unit test for it to test the issue and it fails saying “0% coverage on new code”, even though I did create a unit test for it, thanks!
Will also add if it helps:
I use dotcover for my unit tests as such:
test $(build.sourcesDirectory)\${{parameters.path}}\${{parameters.name}}.sln --no-build --configuration Release --dcXML=“${{parameters.configFilePath}}” --dcReportType=HTML --dcOutput=$(Build.ArtifactStagingDirectory)\${{parameters.name}}-unit-tests.html --logger “trx;LogFilePrefix=${{parameters.name}}-tests”
Parsing the dotCover report E:\azdo\1\_work\1405\a\MySolution-unit-tests\src\
It’s strange that it resulted in 0% coverage. I suspect some kind of path mis-match between what’s in the reports and what analysis sees (although we don’t usually encounter that in .NET).
Given that debug-level logging didn’t give us much to go on here, I’m going to flag this for the team.
Meanwhile, I wanted to point a couple other things out to you:
Fortunately we got verbose logs out of this, but ordinarily you wouldn’t combine these.
You shouldn’t need to provide these manually; they should be picked up automatically from your environment
Did you check the actual HTML coverage file that it really contains the coverage information for your newly added method? And considers that method as covered?
Can you share the coverage file, or its relevant snippets? We can provide a way how to share it in private if needed.
@ganncamp Thanks alot! noted your suggestions and will apply accordingly.
@Pavel_Mikula Hi Pavel! I checked the HTML results file, and it says 100% for the unit test I added (I created a sample pull request to test the issue), the code I added in the pull request was as following (Path censored a bit -Applications/Manager/Console/Secure/UserManagement/AttributeHelper.cs):
public bool TestingSonar()
{
return false;
}
While the unit test I added was as such (Path censored a bit - /Applications/Console.UI.UnitTests/AttributeHelperTests.cs):
[Fact]
public void GivenAttributeHelper_WhenAccessingTestingSonar_ThenReturnsFalse()
{
// Arrange & Act
var result = _helper.TestingSonar();
// Assert
Assert.False(result);
}
So I’m not sure how come Sonar doesn’t catch (SonarQubeBuildSummary.md mentions “0.0% Line Coverage on New Code” therefore fails my pipeline’s policy) that I did add the UT for my new code, while the dotcover coverage report does say that the UT passed. It seems to happen to all of my C# solutions after upgrading from version 9.7 to 2025.1.3 LTA.. If it will help I will definitely be happy to share the dotcover results along with Sonar’s if there is a private way to do so, much appreciating your responses thank you!
I tried to go through the build log, and the coverage report. The setup, and build log seems fine, and I think I’m either missing something about the coverage report, or there’s something wrong with it.
Let’s have GivenPolicyAttributeHelper_WhenAccessingTestingSonar_ThenReturnsFalse. This method is present in the coverage report, and it seems to be 100% covered. That looks OK, but misleading. Because the coverage doesn’t care about the test code itself, it cares about the production code that is subject to the test.
What I’m missing in the coverage report is PolicyAttributeHelper.cs file, and it’s TestingSonar property. And coverage for that.
So to me, it appears that the coverage report is incomplete, and that’s why you have 0% coverage on your Quality Gate.
Do you see the same on your side? I’m not very familiar with dotCover tool, maybe the content of ${{parameters.configFilePath}} can provide more clues.
Let’s try to keep answers in this thread. If you need to share a sensitive data, feel free to reuse the original private channel.
Hi Pavel, thanks a lot for taking a look! Yes indeed I don’t find the PolicyAttributeHelper.cs file but it worked in past versions so I wonder if anything has changed, or if the coverage report should have any code but Unit Tests shown.. I’ve sent you in private the unit_tests_config.xml file contents, and the PolicyAttributeHelper.cs file where I added the TestingSonar function (so the pull request overall only has the TestingSonar function added and the UT “GivenPolicyAttributeHelper_WhenAccessingTestingSonar_ThenReturnsFalse”, thanks again
The config and file looks fairly harmless, as long as your PolicyAttributeHelper.cs lives in the module that you include there. I assume that MyApp.Console was redacted on purpose in the build logs.
If the coverage report does not contain the data, there’s not much our plugin can do. There must be some other change going on at the same time.
I’m not familiar with using dotcover, but I’d recommend as the next steps:
Try to update your XML config to <ModuleMask>*</ModuleMask> and compare the HTML report, to see if there’s not something wrong with the module name detection.
Run the original pipeline against the SQ 9.7, with the same TestingSonar experiment, and export & check the coverage report html from there. And compare it.
As you use SonarQubePrepare@7 for bot analysis (I assume), our Scanner for .NET should not do any changes to your build pipeline in the dotcover configuration. While we interfere with some build properties (like NoWarn, BuildErrors, ErrorLevel, etc), we should not change anything related to coverage instrumentation.
