I’ve compared our PRODUCTION system running SQ Developer Edition 2025.2
with our TEST system running SQ Developer Edition 2026.1.
But systems were analyzed with the same code base and the rule has the same rule configuration.
How to get more details, why the rule does not generate the issue with the same code base?
I did not find any changes in the sonar-dotnet repository on github.
Hi,
That’s a parameterized rule. Do both systems have the same parameter value?
Thx,
Ann
I already wrote, that both systems have the same “rule configuration”.
So, yes the parameter is identical.
Hi,
What language are we talking about? I’d like to check Jira to see if there were any tweaks to the implementation. Also, could we have a pair of screenshots where an issue is/is not raised?
Thx,
Ann
Hi,
Thanks for the language & screenshots. Could you provide a verbose log from the 2026.1 analysis?
Add /d:"sonar.verbose=true" to the Scanner BEGIN step. Examples:
dotnet sonarscanner begin /k:"MyProject" /d:"sonar.verbose=true"
SonarScanner.MSBuild.exe begin /k:"MyProject" /d:"sonar.verbose=true"
- task: SonarCloudPrepare@3 # or SonarQubePrepare@3
inputs:
SonarCloud: 'sonarcloud'
organization: 'foo'
scannerMode: 'dotnet'
projectKey: 'foo_sonar-scanning-someconsoleapp'
projectName: 'sonar-scanning-someconsoleapp'
extraProperties: |
sonar.verbose=true
Please note that most of the relevant logging will happen during the END step, i.e. in SonarCloudAnalyze, SonarQubeAnalyze or Run Code Analysis.
MsBuild.exe /t:Rebuild /v:d
or
dotnet build -v:d
Thx,
Ann
The logs a huge and contains some information I do not want to share in public feed.
What information you are searching for?
Hi,
I’m not sure what I’m looking for. Feel free to redact as necessary.
Looking back at your screenshots, both seem to show an issue. You’ve even added a remark to that effect in the “Without issue” screenshot. Where were you expecting to see an issue in that screenshot that you didn’t?
Thx,
Ann
I expect the issue at line 209: This is the 3rd level of control flow, while, try and if.
I’m working on redacted logs…
Hi,
Thanks for the logs. Nothing jumps out at me. I’ve flagged this for the language experts.
Ann
Hi @lg2de,
Thanks for the logs. I looked through them and the analyzer is detecting S134 at line 209 of NamedPipeServerMedium.cs — the issue is added and the report is successfully uploaded to the server. So this is not an analyzer regression. In fact, the rule detection logic hasn’t changed since November 2021.
You can see it in 9_Build DEBUG for Coverage.txt at line 178941:
src\***.Common\Ipc\Medium\NamedPipeServerMedium.cs(209,21): Warning S134: Refactor this code to not nest more than 3 control flow statements.
Could you check whether the issue shows up when you switch from the New Code tab to Overall Code in SQ 2026.1?
With that information I searched for closed issues. I found that a colleague of me had accepted the issue long time ago.
Because the affected system is a test system I would never have thought of that someone has modified issues there.
So, I’m very sorry for disturbing you.
Hi @lg2de,
Glad you found the root cause! No worries at all — these things are easy to miss, especially on a test system where someone else might have touched the issues. Thanks for taking the time to follow up with the resolution.
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.