SonarQube 9.5
One of the features of 9.5 is more support for C#10 language features.
This is problematic if your codebase only targets older versions of the language as you get a violation telling you to change code to something that you cannot support.
Is there any way to identify rules which as C#10 or 9 specific and exclude those from analyses?
Hey there.
Do you have an example of such an issue/rule? We have the ability to detect the language version during analysis and ensure only relevant issues are raised.
Hi @Colin
constant interpolated strings is the one that keeps tripping me up: What's new in C# 10 - C# Guide | Microsoft Docs
Sonar is telling me to make an interpolated var a const and if I do it then compilation fails because we are on an older version.
Hi @tbutler
Mainly record structs.
That seems to be a nasty false positive because we don’t take into consideration that interpolated strings cannot be constant - could you please give us more details on what is the rule that raises this issue?
is it C# static code analysis: "static readonly" constants should be "const" instead?
Hi
So I get a csharpsquid:S3353 on a line like this:
var message = $"This is a {nameof(Test)}";
If I change it to
const string message = $"This is a {nameof(Test)}";
Then I get a compile time failure:
CS8400 - Feature ‘constant interpolated strings’ is not available in C# 8.0. Please use language version 10.0 or greater
Hi @tbutler,
I wouldn’t call S3353 a false positive in this case. You can still do
const string message = "This is a " + nameof(Test);
in lower versions of C#. The message “Add the ‘const’ modifier to 'message '.” is a bit unprecise here because you have to also change your code. Nevertheless a compile time const should be preferred over runtime string formating.
Best regards, Martin
In any other case where I am told to make the variable a const, the solution is to replace “var” with “const”.
It is a very poor experience to get the same error with the same message but the solution is quite different.
Sonar simply wants me to change it exactly as I described and it is then satisfied. It should know that this format is not supported in earlier versions of C#
Therefore it is a false report IMO.
That a const is preferable over runtime formatting is orthogonal to the fact that Sonar is telling me to do something that simply won’t work.
Perhaps you can detect earlier versions of C# and output a different message, telling you how to fix it in a way that is compatible with the language version.
The only thing worse than not being told how to fix a problem is being told the wrong solution to the problem’
Hi @tbutler,
I agree that the user experience in that particular case is sub-optimal and we should improve the documentation and the error message. I created S3353: Error message unprecise for C# version 9 and below · Issue #5868 · SonarSource/sonar-dotnet · GitHub for us to track work on this.
Thanks @Martin_Strecker
I guess there is no workaround at the moment other than disabling the rule or “just knowing” the right way to fix the issue?
Hi @tbutler
That is right. But, as you already stated, we can improve on the “just knowing” part by educating users via better messages and rule documentation.
Is there any way to identify rules which as C#10 or 9 specific and exclude those from analyses?
There are no rules exclusively for new language features for C#9 or C# 10. We recently made existing rules aware of new language features, so we have fewer False Negatives.
Following, you can find a deeper explanation of the “const interpolated string” and how it appeared, in case you are interested.
For the constant detection, we rely on Roslyn to tell us whether an expression is a compile time constant.
The version of Roslyn that chipped with C# 10 considers an interpolated string a compile-time constant, while earlier versions do not. We did not actively change our detection code here, but the rule is raised automagically depending on Roslyn’s version.