Editor's Note: This blog post contains outdated information. You can find the latest on SonarQube Server here and SonarQube for IDE here.
TL;DR overview
- SonarAnalyzer for C is the rule engine powering static analysis of C code within SonarQube, offering hundreds of rules covering bugs, code smells, security vulnerabilities, and compliance standards including MISRA C and CWE.
- The analyzer uses symbolic execution and taint analysis to detect complex issues that simple pattern-matching tools miss, such as null pointer dereferences, memory leaks, and buffer overruns.
- Rules are continuously refined based on real-world vulnerability research, ensuring that C developers receive accurate, low-noise feedback relevant to the security and reliability challenges of systems and embedded software.
- SonarQube for IDE brings C analysis inline as developers write code, catching issues immediately rather than waiting for a full CI/CD scan.
If you’ve been following the releases of the Scanner for MsBuild and the C# plugin over the last two years, you must have noticed that we significantly improved our integration with the build tool and at the same time added a lot of new rules. Also, we introduced SonarQube for IDE: Visual Studio, a new tool to analyze code inside the IDE. With these steps completed we are deprecating the SonarQube Server ReSharper plugin to be able to provide a consistent, high-level experience among our tools.
In the last couple years we’ve worked in close collaboration with Microsoft to make our products fit easily into the .NET ecosystem. The goal of the collaboration was two-fold:
- integrate the SonarQube Server Scanner for MsBuild seamlessly into the build process
- develop the Connected Mode in SonarQube for IDE: Visual Studio to propagate analysis settings from SonarQube Server to Visual Studio.
The improvements to the SonarQube Server Scanner for MsBuild resulted in pre- and post-build command line steps that respectively download settings from, and upload analysis results to your SonarQube Server. And in between these steps, your MsBuild step doesn’t need to be changed at all. In addition to the SonarQube for IDE Connected Mode, we achieved our main goal of showing the exact same issues inside the IDE as you’d see on the SonarQube Server.
From a technology perspective, both of these integration pieces are highly dependent on the new .NET compiler platform, Roslyn. Additionally, we’ve put a great deal of effort into implementing rules based on Roslyn. From SonarQube for IDE: Visual Studio version 1.0, which was released on July 20, 2015 with 76 rules, we’ve increased our C# offerings to 173 rules. Our C# rule engine, the SonarAnalyzer for C#, is the underlying rule engine in both SonarQube for IDE: Visual Studio and the C# plugin. So no matter where you’re running the analysis, you benefit from the new rules. Many of the rules might have already been familiar to you, because we prioritized the implementation of ReSharper-like rules. We went through all the C# warning rules that are enabled by default in ReSharper and in the end we found that more than 80% of them are now covered by the SonarAnalyzer for C#.
We even went a step further, and made the SonarQube Server Roslyn SDK to provide a way to integrate your Roslyn-based rules into the analysis process both inside the IDE and with the Scanner for MSBuild. However, we can’t provide the same consistent user experience with ReSharper because it’s not based on Roslyn. ReSharper analysis in the build process isn’t MSBuild-based; it requires a dedicated command line tool. And inside Visual Studio, ReSharper is a completely separate analysis tool, so there’s no way to make the Connected Mode support ReSharper settings. As a result, we decided to deprecate the ReSharper plugin and move it to the community maintained extensions.
To sum up, in order to best focus our efforts on valuable features and provide you with the best user experience, we decided to drop support for the ReSharper plugin. “Less is More” is our frequently repeated mantra at SonarSource. With this step, you’ll have fewer tools to worry about, and a more consistent experience across our products. Additionally, you’ll benefit from our quick release cycles, and get updates every months or so. Recently, we’ve focused our efforts on advanced bug detection rules. Did you know that our brand new symbolic execution engine found a NullReferenceException bug in Roslyn?