I have a new project on SonarCloud which is analyzing a fairly new C# solution which contains a tiny amount of code at present. I have installed the latest version of SonarLint and successfully connected the project to the SonarCloud project I have set up. The SonarCloud tasks are part of the VSTS build definition and the analysis is running on build with results being reported to SonarCloud.
Some issues - such as "S2933 - Fields that are only assigned in the constructor should be readonly" are reported in SonarCloud and reported in the VS IDE warnings window when code analysis is run locally. This is what I was expecting.
Other issues, such as "S1451 - Add or update the header of this file" are only reported in the IDE.
Some other issues, such as "common-cs:InsufficientCommentDensity" are only reported on SonarCloud, and not in the IDE.
I would like the IDE and SonarCloud to report the same issues as each other; my understanding is that that is the whole point of SonarLint connected mode.
I have created a custom Quality Profile on SonarCloud that inherits from "C# - Sonar way" and activated every rule, which now total 330, although bizarrely when I view anything beyond the first 100 rules on the website I am always presented with the "Activate" button nomatter how many times I click it and refresh the page.
If I look at the ruleset file that SonarQube has added to the project in VS, it contains the 330 rules that are in the server quality profile and has ticks next to all of them. There are a further 10 or so rules in this ruleset file that are deactivated and do not appear at all on SonarCloud.
What do I have to do to make the IDE and VSTS analyses consistent?
Some rules act a bit weird indeed.
S1451 has parameter (the expected file header) and is thus disabled unless you manually configure it. Even in connected mode SonarLint for Visual Studio does not support synchronization of parameters. This feature is in our backlog and most probably we will be working on it soon.
common-cs:* is a server-side rule (e.g. it runs on SonarQube/SonarCloud) and cannot be executed in SonarLint for Visual Studio.
You could configure the S1451 and the other parametrized rules by adding a new XML file with content similar to this file (link), then reference the file in your project like we do (link).
I was unable to reproduce the QualityProfile Active/Inactive status problem, it would be helpful to share what browser/version are you using and perhaps a short screen capture video of the behavior would be a nice way to demonstrate the problem.
Update: Apparently one of our SonarQube devs managed to reproduce the problem with the QP rule activation/deactivation and created a ticket:
https://jira.sonarsource.com/browse/SONAR-10685
Related
We've created a number of C# code snippets. If I import them directly using the Code Snippets Manager they work perfectly as intended.
Since we are going to have people rolling into our project at different moments in time we want to ease the on-boarding process so we want to include these snippets into a VSIX project. For that purpose I followed this process to the letter.
Now there are several issues going on:
1. When I run the VSIX in debug mode I get the experimental instance of visual studio but the scripts' folder is not in the manager and the package does not seem to be installed when I look in the "Extensions and updates".
If I close VS and run the VSIX installer, after re-opening VS I can see the package installed in "Extensions and updates", I can see the custom scripts' folder in the scripts manager and all the scripts are there but, when I open a code file and try to use them they are just not available, the short cuts are not recognized and the scripts are not available in the insert script context menu.
We have tried both approaches in three different environments and the behavior is the same.
We are using Visual Studio 2017 with .Net Framework 4.7.1
I have tripled checked all the settings, made sure there aren't any typos, all the files that need to be added are there in the right place so I do not know what else to check or try.
I am sorry that I do not include any code but there are some things that are deemed confidential but I tried doing it with the Hello World example and I got the same result.
Thank you for any help you can provide.
So as it turned out, there were multiple causes for this behavior.
Environment 1: With the brand new instance of Visual Studio 2017 there was a folder in the Snippets Manager named %LCID%. Within this folder there were two snippets specifically for MVC 4 applications. We do not know why but either these snippets or the folder was preventing our custom ones to be detected, once we removed this folder everything started working as expected.
Environment 2: This environment did not have the %LCID% folder but had ReSharper installed on it and it was configured to use the IntelliJ keyboard schema. As soon as we changed it to use the Visual Studio one then the snippets became available.
Environment 3: In this one the %LCID% folder was not present and the ReSharper keyboard configuration was set to Visual Studio. We disabled ReSharper and the snippets would still not be available. We basically were never able to figure out why the snippets were not available so we ended up going to the file system, cutting them from the custom folder and pasting them under the "My Snippets" default one and they became available.
Hopefully this information will be useful for someone or, even better, somebody might be able to explain why situations one and three would cause the snippets to not be available.
I have a build machine setup with Visual Studio 2015 Update 3 and sonnarqube msbuild scanner 2.2.0.24. On the sonar server side (6.2), I have c# plug-in version 5.5.2.537.
Upon analysing projects, some code smells are not found in the c# files.
I have verified that :
Sonar project is using appropriate quality profile.
Quality profile
contains the rule and said rule is correcly activated.
I have deleted the whole project in sonarqube and re-run the analysis multiple times. For example in a particular .cs file I have the comment density code smell working correcly. However, the rule about handling TODO (s1135) is not working even though I have multiple TODO in the file. Same goes for the rule "Boolean checks should not be inverted" (S1940) that I introduced in the code for testing purpose.
What could cause those issues to not be reported?
I have moved everything to a new build server. Using the same setup and project, all the issues are now correctly reported.
My company develops a quite extensive .net application, consisting of multiple projects, all hosted on a Team Foundation Server. I'm currently working on a companion app (Windows Phone 8.1, c# and XAML), which is quite small, has it's own solution but also is part of the VCS. When I try to check in, Visual Studio 2015 gives me a policy warning:
The Code Analysis settings for one or more projects are not compatible with Code Analysis policy.
On Double-clicking that message, it lists several rules which it claims are not present in the project settings (Including a dubious "rule 0"). The thing is, in the Project Settings I've set up the Code Analysis to use the same Rule Set the rest of the application is using. And this rule set, when I open it, does actually contain the rules that VS claims are not present in the settings (except for that rule 0). I'm stuck here, any suggestions at what could be going wrong or what else I could try would be greatly appreciated.
(And yes, I know I can override the warning, but I'd actually like to get the Code Analysis working.)
EDIT: I've checked the Release and Debug configurations. We even have separate rule sets for the two configurations, but they both seem to be set up correctly.
One thing that can help with weird policy errors when everything is configured ok with regards to Debug / Release rulesets, and where a rebuild doesn't clear it is to delete the suo file. (This is the Solution User Options file).
Steps:
Close Studio
Delete the SUO (for Visual Studio 2015, this is in the .vs folder)
Reopen Studio
It turned out I had to actually build the release configuration and check in with that build active.
It went back to not working again after the other answer temporarily worked, and going over this in detail with a colleague, he finally pointed that out to me, that usually the check-in should happen with the release build, not the debug one.
Visual Studio was incredibly unhelpful with its error messages about this, and I'm still not sure why I was temporarily able to check in with the debug build, but it's now up and running fine.
Background
I am running Visual Studio 2015 Enterprise (RTM) and have enabled the SonarLint extension for code analysis of my multi-project ASP.NET 4.5 MVC solution.
Problem
SonarLint analysis seems to be ignoring the project setting for Code Analysis "Suppress results from generated code (managed only)"
That is, I'm getting a lot of Sonar errors reported back for a couple of *.designer.cs files generated from some .aspx pages. (Most of the project is MVC, for what it's worth.) I don't care about these errors, and don't think I have a decent path for fixing them...
More Details
I have SonarQube integrated with our TFS 2013 environment, and it is correctly ignoring these issues on the TFS server analysis. This problem is just showing up in Visual Studio, using the Roslyn analysis.
Any ideas how I can set up the equivalent of an .ignore file or otherwise fix this?
There is no built-in way of ignoring files in Roslyn at the moment, so you can't do it. Each analyzer needs to decide if the analyzed file needs to be checked or not. Specifically for SonarLint, I've created an issue on GitHub: https://github.com/SonarSource/sonarlint-vs/issues/85. You can track its progress.
Creating a plain C# Console App in Visual Studio 2015 Preview, we get a pseudo reference named "Analyzers":
What does the "Analyzers" reference just above mean?
The project file has nothing inside and the properties window shows nothing (completely blank) about this entry (though, in contrast to "reference properties" it says "folder properties" in the header, but that does not say much).
I would expect this to be related to Roslyn, but I have no idea. I have ReSharper installed, but I don't assume it has anything to do with it.
Edit 6.8.2016
The accepted answer explains the tooling provided by analyzers, but leaves open why a development tool becomes a (runtime?) reference. Actually it is not a runtime reference, unlike the other references. So the answer to this miracle is Hans Passants comment below:
They picked a clumsy place to add the code analyzers feature, they just couldn't find a better place without drastically overhauling the solution explorer and nuget. – Hans Passant May 26 '15 at 8:59
Live Code Analyzers are used to add custom error messages and warnings that appear live as you're typing, along with automatic code fixes to help you clean them up. They are available as NuGet packages that you add to your projects in Visual Studio 2015.
It is one of the best and helpful key new features of Visual Studio 2015 that lets a NuGet package enable custom warnings and errors in the editor live as you type the code, with automatic code fixes that can clean up those issues for us.
Packages can even be bundled together as a “code-aware library” that pulls in both an API and the domain-specific analyzers to make sure that you stay on course when using it.
We'll have a targeted guidance from the moment we download the NuGet package. And because these analyzers are part of our project, everyone on your team gets to see the same warnings.
Edit 1 :
Analyzers have rules attached to them like below :
These rules focus on the most critical problems in your code,
including potential security holes, application crashes, and other
important logic and design errors. You should include this rule set in
any custom rule set you create for your projects.
Currently there are a number of good Analyzers available – Microsoft.AnalyzerPowerPack, Code Cracker, CSharp Essentials, SonarLint etc
Each of these analyzers have their own rule set, so we can decide which analyzer to add, based on our requirements. Once installed via Nuget, the light bulbs and quick actions in VS2015 will pick up the associated rule set and provide the developers with coding assistance on the fly.