Some time ago I blogged about new Omnisharp features – support for analyzers and support for Editorconfig. Those were at the time two of the most requested features on Github that we had. Today I wanted to let you know that we just shipped another one of those hugely requested functionalities – support for unimported types. In fact, since those previous two have been dealt with, this was the most requested feature that we had.
Browsing posts in: omnisharp
Semantic highlighting in OmniSharp and C# extension for VS Code
Two days ago I blogged about doing semantic classification of C# code using Roslyn. Today, I wanted to draw your attention to a new feature we have recently shipped in OmniSharp and which is now available as experimental feature in C# extension for VS Code, and that's improved OmniSharp semantic highlighting.
Decompilation support in OmniSharp and C# Extension for VS Code
One of the nice new features that we shipped in OmniSharp recently, and that has already made its way into the C# Extension for VS Code is support for decompilation. It was released in April as part of 1.35.0 release of OmniSharp. Let's have a quick look at how you can get it up and running.
.NET 5 preview support in OmniSharp and C# Extension for VS Code
As we all know, we have recently been spoiled with the first preview release of .NET 5. Additionaly, Preview 2 is just around the corner and is already available via dotnet-install scripts.
While it's still early days, we would want that OmniSharp users can work with .NET 5 as soon as possible, so we have just added support for .NET 5 in OmniSharp.
Let me quickly walk you through what you need to do to take advantage of that.
Hidden features of OmniSharp and C# extension for VS Code
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.
Enforcing C# EditorConfig formatting conventions at build time
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.
dotnet-script 0.50 is out – with support for .NET Core 3.0!
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.
EditorConfig support in OmniSharp and C# extension VS Code
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.
Roslyn analyzers and code fixes in OmniSharp and VS Code
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.
Using Roslyn refactorings with OmniSharp and Visual Studio Code
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.