csharpsquid:S3900 - Method parameter annotation with [NotNull] does not work

SonarQube Cloud
,
1

Note: We are running “SonarQube Enterprise Edition v2025.1 (102418) Standard Experience“.

I am annotating Method parameters with [NotNull] attribute from JetBrains.Annotations namespace, but SonarQube just ignores it and complains about violation. In the explanation to the violation, the annotation is one of recommended ways.

The IDE shows the violation at the method call, when a null is provided.

I would like to avoid boiler plate code checking for null, when it will never happen when annotated. What could be the reason it is not sufficient for SonarQube?

Regards
Eugen

4

Just out of curiosity, why not [System.Diagnostics.CodeAnalysis.NotNull]? I’m not sure if Sonar takes those into account though. (I guess they do)

5

This also my first try, but it did not work. So I switched to from SonarQube recommended ReSharper.Annotations, which did not work too.

Your comment sounds that [System.Diagnostics.CodeAnalysis.NotNull]works for you?!

6

Since I started using nullable annotations I never needed [NotNull] anymore. I sometimes still use [NotNullWhen], and [DoesNotReturn].

I also tent to use the [Pure] attribute a lot for libraries I build. I would not recommend usage for non-library projects though.

See: Attributes interpreted by the compiler: Nullable static analysis - C# reference | Microsoft Learn

7

Hi @Eugen_Kremer,

Can you show a snippet of your code where the rule is raised, including the invocation of the validation method that you’re using inside that - where the validation method should have the [NotNull] attribute on its parameter?

The JetBrains attributes should work there, as they are widely used.

9

Hi @Pavel_Mikula ,

below the screenshot from dashboard.

image
image738×174 8.5 KB

The reference to JetBrains.Annotations is done via Directory.Build.props file

<Project>
  <ItemGroup>
    <PackageReference Include="JetBrains.Annotations" Version="2025.2.2">
      <PrivateAssets>all</PrivateAssets>
    </PackageReference>
  </ItemGroup>
</Project>

In the .csproj

    <PropertyGroup>
        <OutputType>Exe</OutputType>
        <TargetFramework>net8.0</TargetFramework>
        <ImplicitUsings>enable</ImplicitUsings>
        <Nullable>enable</Nullable>
        <!-- more ... -->
    </PropertyGroup>


~ $ dotnet sonarscanner --help
SonarScanner for MSBuild 10.3
Using the .NET Core version of the Scanner for MSBuild
10

That’s not how the [NotNull] should be used here to comply with the rule, see RSPEC-3900

The [NotNull] is recognized if you’d use a validation method that you pass your parameter to for actual validation.

By adding [NotNull] attribute on your own parameter, you’re adding just annotation that effectively means “I wish nobody sends me null values”, but that does not prevent such values from actually arriving and causing runtime issues. So as long as you want the rule to be active, it still raises a true positive here.

This rule is in general rather noisy, and we plan to split it to better cover the needs of nullable-annotated code differently in libraries and other projects, but we don’t have an ETA for implementing that. The original thread was here for reference NET-1872 S3900 FP: with nullable context enabled · Issue #5217 · SonarSource/sonar-dotnet · GitHub

11

Thanks for clarification and issue link!

As long as the split of the rule is not done, I need to disable this rule.

1 Like
13

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