Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Option Analyzer (1096i) is not considered when using .editorconfig #758

Closed
stevenengland opened this issue Jan 5, 2021 · 4 comments
Closed

Comments

@stevenengland
Copy link

stevenengland commented Jan 5, 2021

Product and Version Used:
latest Roslynator Analyzer Nuget in a .NET core lib.
Steps to Reproduce:
In my editorconfig file I place those rules

#RCS1096: Convert 'HasFlag' call to bitwise operation (or vice versa)
dotnet_diagnostic.RCS1096.severity=warning
#RCS1096i: Convert bitwise operation to 'HasFlag' call
dotnet_diagnostic.RCS1096i.severity=warning

Actual Behavior:
But the option (1096i) does not override the behaviour of the parent rule (1096). I tried different severity constellations also. The parent rule is considered, I can see the change of severity in the error report if I change it in the editorconfig. Only the option is not recognized/considered.

Expected Behavior:
The options should override the parents when using an editorconfig so that 1096 is not reported anymore.

@josefpihrt
Copy link
Collaborator

Thanks for your report.

I have bad news and good news.

Bad news is that this format of analyzer option does not work when using editorconfig (works only when using ruleset).

Good news that there will be added "editorconfig options" which will be preferred to "ruleset options".

The reason to implement these ruleset options was that there was no possibility to add some kind of options to analyzers other than to use ruleset format. But now with the new version of Roslyn API it is possible to use editorconfig to provide analyzer options.

It will probably look like this:

roslynator.RCS1096.invert = true

@stevenengland
Copy link
Author

Hi Josef, thank you very much for your reply. I am looking forward for these options. Great work!

@asears
Copy link
Contributor

asears commented Jan 17, 2021

Hi Joseph,

Currently implementing Roslynator across a fairly large codebase. I am curious to know if the documentation and readme's should now be slanted more towards using .editorconfig rather than ruleset files? This seems to be go-forward approach put forth by Microsoft to configuring static code scanners with Visual Studio versions 16.5+, along with using modern SDK-style projects.

I have a few questions, let me know if this is correct forum.

  1. Are both .editorconfig and rulesets files required when using VS earlier than 2019 16.5 or mixed VSCode/Visual Studio/AzDevops environments?
  2. Are .rulesets going to be deprecated in favour of .editorconfig?
  3. In your opinion, is it too early to do this kind of migration?

We are currently troubleshooting behavior where a build works in Az Devops and using VS 16.5+, build fails due to missing Microsoft.CodeAnalysis dependency in older VS 2019 versions. Will open another issue for this if we don't track it down. Seems the VS IDE tooling for Code Analysis with FXCop changed across minor versions which broke backwards compatibility of Roslynator.

There seems to be some deficiencies in the .editorconfig tooling as you mention in issues such as above, would these need to be added to documentation?

Thanks for this awesome tool.

@josefpihrt
Copy link
Collaborator

Hi,

First of all I'm glad that you like Roslynator.

Your post is mainly about ruleset vs. editorconfig.

There are two basic levels of configuration

  • Turn analyzers on/off (set its severity)
  • Tweak behavior of a specific analyzer

1) Turn analyzers on/off (set its severity)

You can use both ruleset and editorconfig. The difference is that ruleset scope is project whereas editorconfig scope is folder (and subfolders).

2) Tweak behavior of a specific analyzer

The ruleset format is actually very limited. It supports only <ANALYZER_ID> = <SEVERITY> and nothing else.
The editorconfig becomes very handy here because it allows to pass any value in a format <KEY> = <VALUE>.

Roslynator will support options in a following format:

roslynator.RCSxxxx.<OPTION> = <VALUE>

EditorConfig Support

Here it is important to mention that there is no Roslynator-specific implementation when it comes to processing editorconfig files. Roslynator can support editorconfig as soon as Roslyn API supports it. And it turned out that only Roslyn 3.8.0 has API that allows Roslynator to fully support editorconfig.

Summary

The next version of Roslynator will fully support editorconfig. It will references Roslyn 3.8.0 which means that it will require at least VS 16.8.

Your Questions

Are both .editorconfig and rulesets files required when using VS earlier than 2019 16.5 or mixed VSCode/Visual Studio/AzDevops environments?

Sorry, I don't understand this question.

Are .rulesets going to be deprecated in favour of .editorconfig?

This question should go to Microsoft but I don't think it will happen because they have to keep backward compatibility.

In your opinion, is it too early to do this kind of migration?

I think that it is too early to completely dump rulesets in favor of editorconfig. The reason is that Roslynator does not fully support editorconfig yet. And other similar tools may not support it as well.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants