A while ago, I blogged about using Roslyn's completion service. In today's post, I wanted to continue looking at some of the excellent compiler features that can be utilized to build IDE-like features in your projects. This time, we will look at how to do semantic classification of the code using Roslyn.
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.
In this post I wanted to show you how to write and embed a C# interactive shell (a REPL – read-evaluate-print-loop) in a browser, on top of WebAssembly.
The REPL will give you fully fledged C# interactive development playground, while still being completely sandboxed in the browser environment. I originally wrote this example for my session at Dotnet Cologne on May 10 this year.
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.
Since the beginning of .NET Core, the one feature that I have been most anxiously waiting for, has been support for collectible assemblies. It took a while (a while!), but finally, in .NET Core 3.0 (at the time of writing 3.0.0-preview-27122-01 from 2018-12-04), it’s here.
It’s going to be a killer functionality, that will support some excellent use cases in .NET Core – especially around application plugins, extensibility and dynamic assembly generation.
Let’s have a quick look at how we can load and unload assemblies in .NET Core.
I am involved in a few open source projects built around the Roslyn compiler. One of those projects is OmniSharp, which brings intellisense and C# language services to a number of editors out there, allowing them to provide for their users a rich C# code authoring experience.
Which actually brings me to the point of today’s post. Roslyn is a compiler-as-a-service that you can embed in your own app, and when you do that, you could reach into its C# language services (more specifically, CompletionService) and easily build your own C# intellisense engine.
However, this is not really documented, so I wanted to use this post to show you how you can get started with that.
It's that time again, the new dotnet-script release, version 0.27.0 is out. It's been 2+ months since the last release so this one is fully packed with great features.
You can get it by running dotnet tool install dotnet-script -g (if you don't have it installed yet) or dotnet tool update dotnet-script -g (if you just need an update).
Let me quickly walk you through some of them.
Both the C# compiler and the CLR/CoreCLR runtimes contain a bunch of rules that are in place to save us from ourselves (and to allow us to write code without needing to fully understand ECMA-334 C# Language Specification). That said, there are times where we want to do some things that are normally not allowed, and a good example of that is reaching into reflection to execute some private or internal code.
Today I wanted to show you how to do something quite cool – how to bypass the type/member visibility rules using the Roslyn compiler. In other words, how to get access to internal and private members without needing to use reflection or something like InternalsVisibleToAttribute.