How to hide .NET code style issues (IDExxxx) from SonarQube?

SonarQube Cloud
,
1
  • ALM used: Azure DevOps
  • CI system used: Azure DevOps
  • Scanner command: SonarCloudAnalyze@4 (with scannerMode: 'dotnet' in SonarCloudPrepare@4)
  • Languages of the repository: C#, JSON, XML, YAML
  • Only if the SonarCloud project is public, the URL: private
  • Error observed: See below
  • Steps to reproduce: See below
  • Potential workaround: Unknown

My solutions use an .editorconfig file to configure .NET code style rules (error codes IDExxxx).
In addition, I’ve set the EnforceCodeStyleInBuild property. This causes some - but not all - code style rules to show up as build warnings.

The problem is that SonarQube Cloud seems to somehow pick up code style rule violations that do not show up as build warnings. For example, the SonarQube Cloud web UI shows violations of the rules IDE0046 as “roslyn:IDE0046” with the note “Issue detected by an external rule engine: roslyn”.
But those rules only show up as messages/suggestions in my IDE. And they do not show up in the Azure DevOps pipeline logs (neither in the build task, nor in any SonarQube task).

Why and how is SonarQube picking those up?
How can I prevent this? (Note that I don’t want to excluce all IDExxxx violations. SonarQube should just see the ones that are a build warning.)

2

Hey @Manuel.P, are you perhaps suppressing warnings for those rules? For example:

  • dotnet_diagnostic.IDE0046.severity = suggestion in .editorconfig?
  • <NoWarn>$(NoWarn);IDE0046</NoWarn> in .csproj or Directory.Build.props?
3

No, I’m not suppressing anything for those style rules. A search for IDE0046 in all files of my repository returns 0 results.

The only configuration I have is with the named EditorConfig setting, where I also set it to just be a suggestion:
dotnet_style_prefer_conditional_expression_over_return = true:suggestion
And because this is not a warning (or error), EnforceCodeStyleInBuild does not promote it to a build warning/error.

edit: And even if I would have such an suppression, shouldn’t this then explicitly hide it in SonarQube? I do have suppressions for other warnings (even for a few SonarQube error ids), and those are correctly hidden in SonarQube.

4

Yes, a warning suppression would hide it on SonarQube, but there are certain configurations that don’t, and I think the one you’re using is one of those. This is a known issue, there’s an old thread about it and also a ticket to address it (still open, unfortunately). It seems to me that you are running into the same issue. I will flag this for the team in case there’s any additional input the can provide (and to let them know that this issue is still relevant).

In the thread I mentioned, it seems like the user managed to use some workaround successfully, maybe you could try it yourself too.

6

Thanks for those links. The situation looks similar, but not the same.

In the linked thread the user tries to change rules that originate from a SonarQube analyzer (“Sxxxx” rule code), which I assume uses “warning” as a default severity level. So if the server doesn’t respect the settings in the .editorconfig file then it makes sense that it still sees those as warnings.

In my case the rules come from the C# compiler and do not use “warning” as a default level (at least not the “IDExxxx” ones). So even if SonarQube ignores the .editorconfig file, then it should still only see them as a suggestion, right?

Or will SonarQube always display all rules regardless of their severity?
If that is the case, is there a setting to change this? I’d like to ignore all rules that only show up as a suggestion.

About the workaround in the linked thread:
I’d have to specify all IDExxxx rule ids that I do not want to show as a warning. According to the page .NET code style rules that would be around 130 rule ids (minus the ones I do want as warnings, which I’d have to carefully exclude and keep in sync with my .editorconfig files). And since the C# compiler often adds new IDExxxx rules I’d have to update that list constantly.
I don’t think that I want to do that.

One more point:
Please add a note to the ticket that you linked. It should also apply to Global AnalyzerConfig files (both the default .globalconfig file name and custom ones from <GlobalAnalyzerConfigFiles>).

7

May be the opposite of what we advise here?

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <EnforceCodeStyleInBuild>false</EnforceCodeStyleInBuild>
  </PropertyGroup>

</Project>
8

As I’ve written in the first post, I do want EnforceCodeStyleInBuild to be enabled. I want to see a few (as I have configured) code style rules as build warnings. And those should also show up in SonarQube.

My problem is just about the code style rules that are only configured to be suggestions.

9

Sorry, me bad. I did not read your issue properly. Do you use a .globalconfig or .editorcofig to specify the severity of this rules, or are these (all) the default seventies?

10

I do use both an .editorconfig and .globalconfig file. But the .globalconfig file only contains settings for Code quality rules (CAxxxx) and external analyzer rules (added via NuGet packages), so it shouldn’t be relevant for this case.

All Code style rules (IDExxxx) are configured in the .editorconfig file. I use named EditorConfig settings for all rules that have one. Those are set like this:

dotnet_style_prefer_conditional_expression_over_return = true:suggestion
dotnet_style_prefer_auto_properties = true:warning

I set all named rules, even if their default severity would be the same. (I don’t want to rely on defaults.)

For rules that don’t have a named setting I set their severity like this:

# Simplify LINQ expression
dotnet_diagnostic.IDE0120.severity = suggestion
# Simplify LINQ type check and cast
dotnet_diagnostic.IDE0121.severity = warning
11

Hi @Manuel.P,

This is mainly a Roslyn behavior question, and we can’t do much about it. IDExxxx generally appear only in IDE and do not appear in the build logs, nor the analysis Sarif report.
Once you turn on EnforceCodeStyleInBuild, you explicitly ask for all of these issues to be part of your Sarif analysis report.

On the SonarQube side, we read this Sarif report - with whatever your Roslyn compilation exported into that, based on your settings - and import those issues as external issues. We have a setting controlling if external issues should be imported or not, but turning it off would remove all of them, including all other external analyzers that you’re using.

So the question to solve is:
How can you configure your analysis build pipeline to export issues to the Sarif report.

For quick local testing, you can for example use dotnet build --no-incremental /p:ErrorLog=C:\_Temp\Sarif.json to see what your configuration really exports.

As you want different behavior in IDE and in the pipeline, you’ll need different configs there - something like an extra .globalconfig file, injected via the dedicated MsBuild property into your build pipeline. And this addition config file should will need either to:

  • Disable all the rules that you don’t want to import
  • Disable all the styling rules using category suppression mechanism, and then re-enable selectively rules that you want to import.
12

For sake of completeness, there exist a possible workaround using trick described here, if you’d modify WarningLevel property instead: Configuration of WarningsAsErrors for .NET build

This is UNSUPPORTED scenario that will have unpredictable consequences, and I strongly advise not doing it.

Your analysis will be loosing issues unexpectedly.
The snippet might stop working at any time, as it is depends on our internal behavior.

14

Understood, thanks.

Here is one of those messages that I don’t want to see:

        {
          "ruleId": "IDE0046",
          "level": "note",
          "message": "Die If-Anweisung kann vereinfacht werden.",
          "locations": [
            {
              "resultFile": {
                "uri": "file:///some_path",
                "region": {
                  "startLine": 15,
                  "startColumn": 9,
                  "endLine": 15,
                  "endColumn": 11
                }
              }
            }
          ],
          "relatedLocations": [
            {
              "physicalLocation": {
                "uri": "file:///some_path",
                "region": {
                  "startLine": 15,
                  "startColumn": 9,
                  "endLine": 18,
                  "endColumn": 10
                }
              }
            }
          ],
          "properties": {
            "warningLevel": 1
          }
        },

Is it somehow possible to configure SonarQube to not import entries with "level": "note"?

Would that be based on the WarningLevel as contained in the Sarif.json file? Because as you can see above, even with "level": "note" that is still "warningLevel": 1.

15

Unfortunately no. We don’t have any properties for filtering the contents of the imported Sarif.

The WarningLevel property documentation is not very clear about that. We set it to 4 to be able to import all issues from Sarif.

While looking at the Sarif.json, I now realized there’s one more possible workaround:

  1. Run Scanner for .NET begin step
  2. Run build
  3. Update Sarif reports yourself
    • Find all .sonarqube\out\*\Issues.json
    • Delete whatever you don’t want to have there
  4. Run Scanner for .NET end step

As before, this is UNSUPPORTED scenario, as you’ll be working with our internal directory structure and the file location can change without prior notice. Although this one is unlikely to change, and the worst impact is that you’ll get more issue again - less risk than before.

16

Would it be possible do implement this? If yes, could you please see this as a feature request?

Unrelated to this topic, but a note: If you set it to 4, then you’ll overwrite a higher warning level that is automatically set by the .NET SDK. A value greater than 4 is required to get warnings for the .NET warning waves. If you want to force all warning levels then you should use a value like 9999.

17

I’ll notify our PM to log this as an insight, where they track traction on requests.

Thank you for the note! The actual implementation has a condition to take that into account, so we should be fine.

19

@Pavel_Mikula:

This is mainly a Roslyn behavior question, and we can’t do much about it. IDExxxx generally appear only in IDE and do not appear in the build log

Regarding IDExxxx errors not being show on the CLI see Code analysis in .NET | Microsoft Learn

However, for performance reasons, a handful of code-style rules will still apply only in the Visual Studio IDE.

There you find all IDE diagnostics with respective categorization:

image
image786×207 6.35 KB

But I don’t know up to which level the CLI picks up the diagnostic.

22

@carlossus I don’t understand what you want to say with your post. My problem is that SonarQube sees to many rules. Your post would explain why it wouldn’t see enough.

23

Sorry, I messed up the quoting. I was referring to the answer marked as solution which says

This is mainly a Roslyn behavior question, and we can’t do much about it. IDExxxx generally appear only in IDE and do not appear in the build log

which isn’t true in general. I edited my post.