I didn´t understand this bellow difference between SonarLint and SonarQube.
Is my sonarLint configuration missing?
See print bellow
Compare rules from SonarQube to SonarLint
Thanks folks!
For C# code, both SonarLint for VS ("SLVS") and the Scanner for MSBuild ("S4MSB") use the SonarC# Roslyn analyser.
SLVS uses the version of SonarC# embedded in the VSIX; S4MSB uses the version embedded in the SonarQube SonarC# plugin. You might see slightly different sets of issues being reported if different versions of the SonarC# analyser are being used as the analyser is under active development (e.g. new rules being added, false-positives and bugs being fixed).
A more common source of differences is the configuration of the set of rules to be run.
The same default set of rules is used by both SLVS and SonarQube, but this is configurable. In SonarQube, rules configuration is done using Quality Profiles. In VS, it is done using the standard VS ruleset mechanism.
The rule S1244 in your screenshot is disabled by default, so my guess is that your SonarQube project is using a customised Quality Profile that has enabled the rule.
If you are using SLVS in "standalone mode" (i.e. independently of SonarQube/SonarCloud), you'd configure the rules you want to run using rulesets.
If you have a project on SonarQube/SonarCloud and want to use the same set of rules locally in SLVS, you can use "connected mode" to link your VS solution to your SonarQube/SonarCloud project from the Team Explorer in VS. SLVS will generate a ruleset from the Quality Profile and configure the projects in your solution to use the generated ruleset.
Related
I have VS solutions with hundreds of C++ projects built using Azure Devops, these projects have a big mess of different project settings as projects have been created at different times over 2 decades, converted from different VS versions, etc.
We want to standardise some settings for instance building everything using c++17 standard. That's a compiler setting cl.exe /std:c++17 but I cannot see any way we can override this via msbuild/YAML; I'd initially assumed I could set it as a project property msbuild -p:std=c++17 but this isn't possible (for reasons I don't fully understand).
In another couple of years we might want to force all our code to build against the c++20 standard. Equally, we might want to compare builds flip-flopping between two settings. So: is there a way we can apply compiler settings at build-time which override the project-specific settings?
There seem to be two approaches (other than editing all the project files individually):
Use switch p:ForceImportAfterCppTargets on the msbuild command-line. This allows a .props file to be specified which is evaluated and overrides project settings. More information here: MSBuild: Custom.After.Microsoft.Common.targets for native C++ projects in VS2010 and in the docs
Use directory-level file Directory.Build.target file, this will be auto-discovered by msbuild and similarly override project settings.
The one downside is that these methods both seem to only apply to msbuild, not within Visual Studio itself, which can lead to confusion when something will build in the IDE but not on the build agent or vice versa.
I installed the SonarLint extension for Visual Studio and connected successfully to our SonarQube server and successfully ran Code Analysis to display sonar issues in VS. So it was working OK but for some reason I am now no longer getting any sonar Sxxx warnings and instead now see the following 2 warnings:
> Warning CA0507 Post-build Code Analysis (FxCopCmd.exe) has been
> deprecated in favor of FxCop analyzers, which run during build. Refer
> to https://aka.ms/fxcopanalyzers to migrate to FxCop analyzers.
>
> Warning CA0064 : No analysis was performed because the
> specified rule set could not be loaded or did not contain any managed
> code analysis rules.
But I am not using FxCop and I am not aware of having done anything to turn it on.
If I check one rule inside "Managed Binary Analysis" the CA0064 warning will go away, but CA0507 remains and still no sonar Sxxx warnings.
The "Run Code Analysis" menu items only apply to the legacy FxCop rules. You don't need to use those menu items for Roslyn-based analyzers (like the C# and VB.NET rules in SonarLint) - Visual Studio will automatically trigger the analysis in the background. See the Microsoft docs for more info.
If you are not seeing Sxxx issues being reported there are a couple of things to look at:
Check whether you have the Enable full solution analysis option checked. If not, VS will only report issues in open files.
You've connected the solution to your SonarQube server so SonarLint will have generated a ruleset based on the Quality Profile. The ruleset will be in the solution-level .sonarlint folder. Check whether the rules you are expecting to report issues are enabled in the ruleset file. If not, update the Quality Profile on the server then close and re-open the solution. SonarLint will detect that the Quality Profile has changed and prompt you to update it.
Try to Compile again the project. With first compilation this errors will appear but with second compilation probably not.
No idea why, but it worked for me.
Is it possible to analyze C# project using Sonar-runner with sonar-c#-plugin-4.2. I saw the MSBuild SonarQube Runner to be used for C# analysis on the documentation.
Does sonar-runner support C# analysis on sonarqube 5 with C# 4.2
The use of the sonar-runner is no longer supported to analyze C# projects. Indeed, analysis through the MSBuild SonarQube Runner will be of much higher quality because it fully integrates with MSBuild and knows everything about your project, and at the same time also much easier to setup, again because most manual configuration required before is now obtained through MSBuild itself.
At least I managed to run the analysis with the sonar-runner. I consider the new begin-build-end workflow with MSBuild SonarQube Runner a bit complicated while using Jenkins and having plenty of existing scripts in play at least. Or I could not get it working due to slightly TFS-oriented documentation with Visual Studio command prompt being also involved.
I finally, after intensive googling, got the analysis running with my Visual Studio Pro + Jenkins + OpenCover + Mstest + Nunit combination by defining below properties in Invoke Standalone SonarCube Analysis in Jenkins job. I still do not know how to separate integration tests from unit tests. It does not say anywhere is this even supported for C# projects.
Workflow is that I first build everything, then run OpenCover to collect results with coverage and then invoke the runner. The below properties can of course be as file in the root folder of the project as well, but in my initial proof of concept I set these in Jenkins plugin.
sonar.projectName=projectname
sonar.projectKey=key
sonar.ProjectVersion=1.1
sonar.visualstudio.enable=true
sonar.language=cs
sonar.sources=.
sonar.dotnet.visualstudio.solution.file=code.sln
#not sure if the line below is correct or relevant...
sonar.dotnet.visualstudio.testProjectPattern=*Test
#two frameworks producing tests.
sonar.cs.vstest.reportsPaths=relativepath/results.trx
sonar.cs.nunit.reportsPaths=relativepath/testresults.xml
sonar.cs.opencover.reportsPaths=1.xml,2.xml
Is there any way to feed visual studio static analysis on c++ code base into sonar?
Thanks
Did you check out the VSSonarExtension? Some hints on how to use it your can find here.
Update:
The other way around there may be a plugin by jmecosta called VSSonarAddin. One of its features is
"c++, runs local analysis with cppcheck and reports violations added
by local changes. "
You can find the project on github.
The Community C++ Plugin supports feeding compiler warnings as violations into SonarQube. You usually need to build your code with code analysis enabled and later you can use that data during SonarQube analysis. See here for more details!
I have a set of rules defined for Visual Studio Code Analysis and I also configured them in Sonar (http://www.sonarqube.org/). I get different results.
Why?
Code Analysis uses FxCop ? In Sonar I can configure FxCop.
Well, the reason is simple: these are different tools, with different features and capabilities...
In SonarQube, you can configure the quality profile (= rule set) that you want to apply on your project when you analyse it. This rule set is probably very different from the one available in Visual Studio Code Analysis.