Recently, I blogged about Roslyn analyzers support in OmniSharp and C# extension VS Code and some background on how that feature came together.
Today I am pleased to announce that in the latest OmniSharp release - 1.33.0, where we have shipped another large feature (in fact, the 2nd most requested feature in OmniSharp repo, after, well, analyzers) and that is support for EditorConfig.
Between then, and the time it took me to finally write this post, we actually have 1.34.0 which is even better - and is in fact included in the corresponding release 1.21.0 of the C# extension for VS Code.
More after the jump.
EditorConfig - what and how 🔗
The original issue requesting support for EditorConfig was almost as old as the repo itself - over four and a half years. The PR implementing the work can be found here.
Just like many other new OmniSharp features - to not overload the amount of work the server needs to do if you are not interested in it - the feature is opt-in. In order to enable it, you can add the following setting in the OmniSharp configuration model, such as
omnisharp.json file:
{
"RoslynExtensionsOptions": {
"enableAnalyzersSupport": true
},
"FormattingOptions": {
"enableEditorConfigSupport": true
}
}
You could also add a VS Code setting:
"omnisharp.enableEditorConfigSupport": true,
"omnisharp.enableRoslynAnalyzers": true
Note that the above config also enables analyzers support, and while it’s not mandatory, it is recommended for best experience with EditorConfig (as then you’d get maximum amount of suggestions and code fixes).
With EditorConfig in place, you can control the following aspects of your code:
- formatting options (i.e. indentation, spacing, new lines etc.)
- code style options (i.e. prefer var over concrete types etc.)
- naming conventions (i.e. camel casing or pascal casing of members, prefixes etc.)
- analyzer behavior
If you invoke any code fix or refactoring offered by OmniSharp - for example creating a field from constructor argument, then the EditorConfig settings are flown into the code fix and respected.
Here is a concrete example - imagine you use the following rules in your .editorconfig file.
[*.cs]
dotnet_style_qualification_for_field = false
dotnet_naming_style.instance_field_style.capitalization = camel_case
dotnet_naming_style.instance_field_style.required_prefix = _
Now with this setting loaded into OmniSharp, if you generate a field from a constructor argument, OmniSharp instead of generating it with the this. accessor (the default behavior), will skip the accessor. Moreover, the field will be generated with a ___ prefix, rather than the default behavior of just using the argument name straight up.
<p>
Notice that even the "preview" in the selection drop down of refactorings is showing the correct name based on <em>.editorconfig</em>.
</p>
<p>
For a good "real life" EditorConfig file, I recommend to have a look at one that is included in the Roslyn repository - you can find it <a href="https://github.com/dotnet/roslyn/blob/master/.editorconfig">here</a>.
</p>
<p>
Enjoy!
</p>
