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.
Background π
Support for decompilation was one of the most requested features for OmniSharp, so we are thrilled to finally be able to include it into OmniSharp. It is based on the wonderful open source .NET decompiler, ILSpy - the same one that powers decompilation features in Visual Studio. In fact, decompilation support in OmniSharp is very much modelled after how things work in Visual Studio.
Big words of gratitude are also necessary towards the ILSpy maintainers - Christoph and Siegfried who have pushed my lazy self throughout the process to get things finally done and helped us during the implementation phase.
Usage π
The feature, like many other OmniSharp features is opt-in for the time being, meaning it is disabled by default. If you’d like to enable it, you need to add a relevant OmniSharp configuration option:
- to enable it globally, use %USERPROFILE%/.omnisharp/omnisharp.json file
- to enable it for a specific project only, use omnisharp.json at the root of your workspace (typically at the root of the repository, next to solution file)
If the file doesn’t exist, just create it. Then the following setting is needed inside:
{
"RoslynExtensionsOptions": {
"enableDecompilationSupport": true
}
}
This is currently the only way of enabling decompilation - in the future, the C# Extension for VS Code will also get its own extension-level setting, that you could just add into the VS Code settings directly without having to deal with omnisharp.json.
Once enabled, decompilation support is a drop-in replacement for navigating to metadata. In other words, when you try to go to the definition of a symbol that is not part of your source, but rather is externally imported from a DLL (normally a NuGet package reference or a direct DLL reference), instead of showing you the basic metadata view with just member names and signatures, we’ll attempt to perform decompilation instead, and drop you into the relevant declaration location.
This is illustrated on the animation below - with an example of some APIs from the Newtonsoft.Json NuGet package reference.
There are some known limitations at the moment around reference assemblies - those are currently not resolved to the implementation assemblies. This is, I believe, on par with Visual Studio behavior though, which also doesn’t do that (at least not always).
Hope you will find the feature useful!
