OmniSharp powers intellisense and language services in C# plugins and extensions for numerous editors, including VS Code. When we build things into OmniSharp, we typically try to keep things lightweight (of course if the term “lightweight” applies to anything related to MSBuild…) and non-invasive. This means that many features/tweaks are actually opt-in by default, and wouldn't normally show up on their own.
In this post I wanted to show you a few of such less known features.
EditorConfig is an excellent way to enforce stylistic rules on your C# projects. However, the rules and their corresponding IDExxxx diagnostics are only enforced in the editor, such as Visual Studio or VS Code with OmniSharp, but not at build time.
While there are various categories of EditorConfig conventions that you can use, in this post, I will show you how to enforce the formatting conventions (IDE0055) at build time.
We have some exciting news to announce – dotnet-script is now supporting .NET Core 3.0.
We released the new version 0.50.0, with .NET Core 3.0 support already on September 25th, two days after .NET Core 3.0 went RTM, but kept quiet about it. The reason was that a large part of the scripting experience is the tooling in OmniSharp and the C# Extension for VS Code, and that had to be updated accordingly too.
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.
Recently we merged a big (albeit still experimental) feature into OmniSharp – the support for Roslyn analyzers.
I wanted to take a few moments today to discuss this feature with you, share some background info, show you how to get it enabled and share some plans for the next steps.
One of the features that we added to a recent OmniSharp release (which, as a reminder, backs the C# language services in various editors), and that quietly shipped in C# for Visual Studio Code 1.10.0 last week, was the ability to use external Roslyn refactorings.
Before, OmniSharp shipped with some built-in Roslyn refactorings (i.e. move type to file) but this new feature allows a user to import custom refactorings – either self- or 3rd-party built.
It’s still an experimental feature, so it needs to be switched on manually, but hopefully it can provide you some much neeeded productivity boost.
Let’s have a look at how that’s done.
I quite often get or see questions about configuring C# code formatting settings for Visual Studio Code.
OmniSharp (the open source Roslyn-based technology that powers C# language services) in VS Code exposes a rich set of code formatting settings which you can use to tailor and customize your C# experience.
Let’s have a look at how you can use them.
I’ve said it a couple of times already, but I sincerely believe that the OmniSharp project is one of the most important projects in the history of .NET.
Having an alternative to the “dictatorship” of Visual Studio is fundamentally important to the health of the .NET ecosystem, and OmniSharp has done a tremendous job in that sense (thanks, Jason & David). Fro my side, I’ve been trying to support the project as much as I can – by contributing, speaking or blogging about it, trying to spread the love.
This winter I managed to put together a mini tour of Canada with an OmniSharp session. Later this month, and in early March, I’m gonna do 3 talks on the project, and in general doing C# without Visual Studio:
If you happen to be in the area – hope to see you there! I promise it’s gonna be fun!
