This issue is because SonarQube did not find the most severe C# code issues in an analysis. Sonarqube also didn’t find one out three C code issues. I’ll just concentrate on the C# bugs here because in general the C# analysis results were very poor. The C results were better.
The results of a proof of concept put sonarqube in last place of all tools finding C# bugs. The configuration was changed to turn on all C# rules and I’ve done some other things recommended by sonarsource’s consultant, but the results are still underwhelming. I’d like to know if this is a failure of the tool to provide the same high level analysis as their competition. I would be nice to find out the source of this failure of the tool. Is the issue the analysis engine (abstract interpretation, symbolic logic, theorem proving), or is it is the data flow analysis or does the tool not support common rules like CWE properly?
What are your experiences contrasting sonarqube to other top static analysis tools? The number one criteria for selection is finding bugs. If the tool can’t find bugs, then nothing else is as important.
Sonarqube didn’t find any related null pointer issues.
Bug #2 is a stream that is never closed.
catch (Exception e)
{
C.Debug.OutputDebugString(">>>> SecureFile.Save - EXCEPTION = {0}\r\n", e.Message);
//If there was an exception, return false
//Clean up if we can
fs = null;
…
}
For BUG #1, I get a CS8602. Do you get at least that?
Are your sonar rules configured to report csharpsquid:S2259? It may have been disabled since the C# compiler already does this. Do you get any other Null dereference errors in the code in between the icon declaration and the float?
I am using both Coverity SAST and SonarCloud for each PR currently. I’ve also used Codacy in the past along with things like FxCopy/Cat.NET/ etc. They all miss things that the others find and each has its own annoyances-by-design. None of them find all the bugs. SonarCloud has been the easiest to deal with (even though they probably think I dont like them).
Microsoft already has lots of built-in code quality rules as part of its Roslyn compiler for C#. Many of those are disabled by default however, including CS8602 to check for possible null references. You’ll need to enable them, either through a .ruleset file or a .editorconfig file in your Visual Studio project. Once the compiler sees those issues, SonarQube will automatically report them as well, on top of its own issues - see here for further details: Importing Third-Party Issues | SonarQube Docs
There’s no need for SonarQube to duplicate Microsoft’s work here; importing the Roslyn results works really well once this is set up.
Memory issues, such as a stream that isn’t properly disposed, are part of Roslyn’s Reliability ruleset, which again is disabled by default. Just set up the .ruleset or .editorconfig file accordingly, and you’ll see a bug in SonarQube telling you that the stream needs to be disposed of. When I try this in one of my projects, Roslyn pipes up with this rule: CA2000: Dispose objects before losing scope (code analysis) - .NET | Microsoft Docs
Are you sure that you’ve got the correct ruleset enabled?
Firstly, welcome to the community and thanks for the feedback
I’m the Product Manager for the .NET Ecosystem so I’ll try and explain a bit more about our strategy and why you might not always see the issues raised that you are expecting.
We have a team continually working on improving the accuracy of the rules because we know how frustrating false positives can be. To reduce the noise our rules may be more cautious about raising an issue than other analysers. We wont add rules to the default profile in SonarWay until we are confident that they won’t be too noisy - you can add them yourselves if you’re happy they aren’t.
As Chris points out, some issues are well covered by Microsoft’s Analysis and rather than replicate what they do, we allow the import of Microsoft rules into SonarQube. Our plan is to improve the support for the imported Microsoft rules to potentially allow configuration and suppression directly from SonarQube but until then you’ll need to configure them in .editorconfig.
It’s odd you are not seeing an issue for your null references - if you’d like us to take a closer look can you let us know what version of SonarQube you are using and send us a more complete code example.
