New feature: disable autofix for specific rules in .editorConfig

  • Operating system: Windows
  • IDE name and flavor/env: Visual Studio 2022

our team has a new idea for a feature. We already encountered two problems with the autofix-function for specific rules. The rules itself are very useful but the autofix is wrong or not recommended (too many side effects). Also, some developers are saving while writing new code and the autofix-function kicks out eg. unused (or better say “not used yet”) Variables :slight_smile:

So we don’t have to relinquish completely the rules we wanted to turn off the autofix-feature in the EditorConfig where we also control the severity. A solution could look like this:

dotnet_diagnostic.SA1202.autofix = false

It would be so cool if you add this feature in a future version!


Hi urmel,

I’m going to flag this for the SonarLint team, but IMO turning off the autofixes should be an absolute last resort. Instead, we’d far rather fix them. Would you mind identifying the rule(s) and fix(es) in question?


Hello Ann,
I wrote two issues on GitHub for the rules:
S1125 - Bug: S1125 code fix does not add ! when transforming x == false. · Issue #7999 · SonarSource/sonar-dotnet · GitHub
S1127 - autofix: S1172 code fix does not delete unused param in function call · Issue #8187 · SonarSource/sonar-dotnet · GitHub

The other one was S1481 (but I won’t create an issue for that):
My team is used to it to save up regularly. Now if you write a function and declare the variables in the beginning because you want to use it later - save up - it’s gone. So for that rule we definitely need to disable the autofix-function.

I understand that you want to eliminate the root cause. Nevertheless, I see the advantage of having this feature (which is also offered by roslyn-analyzers). It would be cool if we can customize it more (for disabling autofix for until the problem is fixed or even to disable it for specific rules)

Thank you! :slight_smile:

1 Like


Perfect! :star_struck:

I’ve flagged this for the Product Managers



First, thanks for creating those issues!

Second, it seems to me (feel free to correct me if I am wrong), that this is an IDE (Visual Studio) feature, not a Sonar one, and that it is controlled through two things:

  1. Analyze/Code Cleanup/Configure Code Cleanup to choose which code cleanups are applied for a given profile

  2. Tools/Options/Text Editor/Code Cleanup to enable/disable auto apply of a specified profile on save

Do you mean that you specifically cannot control those through this setting? Or is it that you would want a way to share the setting at the project level and not on individual VS setups?

Hello Denis,
thank you for your quick answer!

Indeed, there is this function in Visual Studio. Here, you can configure which rules are applied. We only have one rule that is activated: Fix all warnings and errors set in EditorConfig

The .editorConfig is on our root-level, shared among the different developers via Source Control. We want a more specific approach where we manage individual rules that are perfect for our needs. For example, turn off specific rules we don’t need or lower the severity.

Sometimes we think the rule is useful, but the autofix-feature is not. Therefore, we want to control this specifically for each rule in the .editorConfig. At the moment, we have to turn off the whole rule if we don’t want the autofix.

Example of .editorConfig:

dotnet_diagnostic.S1144.severity = silent
dotnet_diagnostic.S125.severity = suggestion
dotnet_diagnostic.S112.severity = silent
# this would be the new feature to just turn off the autofix
dotnet_diagnostic.SA1202.autofix = false

I hope it’s more clear now, why we need this feature. Feel free to ask any questions :slight_smile:


Hi Urmel,

Thank you for explaining. Would you mind sharing your EditorConfig as it is today, as well as the version of Visual Studio you are using?
I would like to be able to reproduce your issue exactly before responding more precisely.


Hey Denis,

we use "Microsoft Visual Studio 2022 (64-bit) (VS version is 17.7.5)
I attached you our .editorConfig as a .txt-file because .editorConfig is not an allowed extension for upload. The comments are in German, but you can see which rules we disabled completely because we don’t want the autofix-feature.
editorConfig.txt (5.7 KB)


Thank you for sharing,

If I take rule 1481 (remove unused local variables) as an example, I see you have it silenced in your .EditorConfig file.
However, Sonar does not provide a quick fix for this one (as seen on C# static code analysis: Unused local variables should be removed). And, moreover, as far as I know, Visual Studio only applies internal (Microsoft’s own) quick fixes on Code Cleanup.

In my setup, with your EditorConfig, whether I silence the rule S1481 in EditorConfig or not, if my CodeCleanup setup (which is VS-specific, only editable through UI in the Analyze menu) has the “remove unused variables” fixer, it will be applied on save (if the CodeCleanup on Save checkbox is checked in the Options of course).

Now there is an open issue on roslyn for supporting CodeCleanup with .EditorConfig: Easy code cleanup with EditorConfig · Issue #40163 · dotnet/roslyn · GitHub
This is probably the issue you want to track for this feature.

I hope this helps clarify the problem. Please feel free to let me know if I made an error in understanding your problem!


Hello Denis,
thank you for your detailed answer.

Firstly, we know that rules by SonarLint and StyleCop are autofixed. For example the spacing and spaces are fixed by StyleCop. In the ticket because of S1172 that I linked above the developer could reproduce my problem.
I suspect that your settings of the code cleanups aren’t correctly. Could you please share them?

Secondly, I wrote two issues on GitHub for S1125 and S1172, which have an autofix-function. For these rules, we would need that feature. Sorry, if the other comment is wrong in our .editorConfig - I will forward it internally.

Thank you

I think I understand now. I had missed the “Fix all warning and errors set in EditorConfig” Code cleanup entry, which is what ropes in the autofix from Sonar’s rules I think.

So, to summarize:

  • If Code cleanup is configured to apply all fixes from EditorConfig
  • And Apply Code cleanup on save is set
  • And rule S1172 (for example) is not silenced

Then, upon saving the file the undesired (because they are broken) auto fixes are applied, resulting in broken code.

Therefore, you would like fine-grained control over which autofixes are activated in EditorConfig for Sonar’s rules.
This would allow deactivating fixes that you do not want while keeping others.

Is that correct?

For the time being, I would probably remove the “Fix all warning and errors set in EditorConfig” and “Remove unused variables” entries from the Code cleanup configuration to limit the damage on your code base.

Yea, exactly! Thank you for your patience

Additionally, some rules aren’t broken, but we just don’t want the autofix. We just don’t want them be autofixed :slight_smile: We only have the entry “Fix all warning and errors set in EditorConfig” active - it’s saving us a lot of time because we don’t need to format our code anymore.

So we will definitely stick with the .editorConfig-solution - hoping that you will add this feature so we can have our rules and our autofix

Happy to hear we understand where your pain point is.

I will make a note of your requirement, but keep in mind this might not be technically possible at our level. I would definitely urge you to open an issue with Roslyn for such a feature (Issues · dotnet/roslyn · GitHub) because they seem to be driving the work on those things and it should probably be a feature at this level (since that is the common mechanism between VS and VS Code).

Hello Denis,
wouldn’t be a json-file for custom settings of the plugin also possible - for example .eslintrc.json ?

Also, I wrote an issue on GitHub for Roslyn to add that functionality: New feature: disable autofix for specific rules in .editorConfig · Issue #70428 · dotnet/roslyn · GitHub


Hi Urmel,

I think dynamically changing the availability of code-fixes is not possible for SonarLint. I posted a message on your issue to push the idea of including this in EditorConfig as it seems to me a very good idea. Hopefully the Roslyn team will prioritize that!


Thank you!

Should we close this topic now? As far as I understand it, when Roslyn adds this feature SonarLint don’t have to implement it, right?

Yes, exactly. I think we can put this one to rest and focus our efforts on pushing for this feature on their side!