sonarlint-visualstudio
sonarlint-visualstudio copied to clipboard
SonarSource
Investigate impact of switch to .editorconfig on C#/VB projects
Description
Starting in Visual Studio 2019 version 16.5, ruleset files are deprecated in favor of the EditorConfig file for analyzer configuration for managed code.
We need to understand this will have on Connected Mode, if any.
Some questions (there may be others)
- what's the relationship/priority between rulesets and .editorconfig files? i.e. what happens if a project uses both?
- when will support for rulesets be dropped?
- will support for editorconfig be back-ported to earlier versions of VS? (almost certainly not, so we might need to support different configuration mechanisms for different VS versions - or drop support for older versions of VS).
- can editorconfig files be composed in the same way rulesets can? i.e. can we two editorconfig files, one generated and one user-edited? If not, sync-ing the editorconfig with the QP will be more difficult.
- is there a VS API to locate the editorconfig file being used for a project/solution?
- can editorconfig files be used with other languages? (i.e. could we use it as a common settings format for our other supported languages?)
- are MS going to extend the use of editorconfig files e.g. to C++?
Some additional questions:
- what impact does that have on
SonarLint.xml? i.e. can custom analyzer parameters be passed in the editorconfig as an alternative to being passed in as an additional file? If so, which takes precedence etc?
Too early to investigate the impact, the work on MS's side is not completed and there are inconsistencies between the documentation and the observed behavior. We should revise this in the future once a stable version is released.
Removed the blocked label.
MS docs have been updated and now refer to ruleset files as being deprecated.
Note: we still need to support multiple versions of VS, including older versions in which editorconfig files are not supported (and presumably never will be).
Has there been any update on this? 🙂 We're evaluating using SonarLint, but we're already using an .editorconfig file and would prefer for SolarLint's rules to also be put into the .editorconfig file, rather than into a .ruleset file 🙂
I think guys you should invest more on this. I agree with previous comments. The .editorconfig file must be the canonical format for any and all analyzer. Please review this issue.
Much appreciated!
Hey dear sonarlint devs!
Another year has passed and using .editorconfig is clearly the way forward. Any plans to attack this issue?
@koraybalci we have a feature scheduled for Q2 2023 to how Connected Mode works so that there are no changes to project files. Part of this will involve switching from rulesets to .editorconfig files. We done some initial technical investigation and are about to start working on the defining migration experience from the existing Connected Mode configuration.
@duncanp-sonar In our case, I think what we'd like is something like this:
- We manually manage the contents of our
.editorconfigfiles. (We'd probably rather Connected Mode not modify them) - The VS SonarQube plugin adds warnings from SonarQube's special analyzers. (Not sure if it does that today, or is that works with the Sonar Qube business model, though.)
- Connected Mode hides warnings in specific pieces of code that we've suppressed on the SonarQube server. (e.g.
Example.cshas a warning on line 100, and in SonarQube server, we've marked the warning on that line as not relevant. We'd also like to not see that warning in VS).
Just some food for thought 🙂
- We manually manage the contents of our
.editorconfigfiles. (We'd probably rather Connected Mode not modify them)
Same here - we control this file and distribute a central one to teams.
- Connected Mode hides warnings in specific pieces of code that we've suppressed on the SonarQube server. (e.g.
Example.cshas a warning on line 100, and in SonarQube server, we've marked the warning on that line as not relevant. We'd also like to not see that warning in VS).
Agree - Sonar Server and Sonar Lint should show the same results. We'd also like to have a "PR" view to only see new issues vs 1,000's of legacy issues from a mature codebase we have added to Sonar
How does this connected or not connected mode relate to SonarAnalyzer.CSharp NuGet packege?
If SonarLint connected mode will switch to .editorconfig for rules configure, I would like to propose a feature.
The teams in my organization already use a standardized .editorconfig file to ensure we have common code style conventions and .NET SDK code analysis rules across all projects. But we unfortunately have no good way of distributing this to all teams/projects/repositories or to redistribute when modifying the file.
It would be very useful if we could upload our custom base .editorconfig file to SonarQube/SonarCloud with all non-sonar specific settings. Sonar could then append the Sonar scanner specific rules to this "base" file when connecting/updating from Visual Studio.
Such a feature would add a lot of value to the Sonar ecosystem!
The teams in my organization already use a standardized .editorconfig file to ensure we have common code style conventions and .NET SDK code analysis rules across all projects. But we unfortunately have no good way of distributing this to all teams/projects/repositories or to redistribute when modifying the file.
@josundt I'm not sure this is a concern of Sonar tbh so unlikely to get any traction. In my company we do use a github action to "sync" .editorconfig from a repo of coding standards files into multiple .NET repos so that we only need to update the file in one place to get it shared to everyone.
tbutler-qontigo
Sonar provides code analysis scanners, but it has also grown as a ecosystem for static code quality control, supporting external code quality tools. SonarQube/SonarCloud is already capable of including results from external analyzers, e.g. other .NET Roslyn Analyzers, importing eslint/stylelint reports etc.
In my mind it would make sense if Sonar tools like SonarLint also dealt with the distribution of configurations for supported external analyzers. .editorconfig could be a good start, since you could then configure all .NET Roslyn analyzers as well as coding style.
Everything that could make Sonar a more complete ecosystem for code quality control should be a concern unless adding more value is no longer a target.
Done as part of v7.0. Connected Mode now generates .editorconfig files rather than .ruleset files.
CC @marco-comi-sonarsource - see @josundt's suggestion above about distributing config for external analyzers.