Writing plugins for ReSharper and Rider

JetBrains tools are developed with extensibility being a principal goal. In fact, many new features we ship could also be just plugins. However, we realised that specifically the setup experience has been a little entry barrier. If you ever tried to write an IDE extension, we recommend you to try again, because developing ReSharper and Rider plugins becomes a lot easier!

In this blog post, we will guide you through how to get started, and give you some basic advice on how to succeed with your plugin ideas.

Click bait news: “I was typing code and then this happened!”

JetBrains Plugin Repository

Excursion into history

ReSharper supports plugins since the early beginnings. Some time ago, you would just compile your plugin and put the assemblies into the ReSharper bin directory. Or you would pass a /ReSharper.Plugin parameter along with the path to devenv.exe.

The easy times have changed a bit, unfortunately. This happened foremost because of the growing ecosystem around our .NET tools – hello dotPeek, dotTrace, and dotMemory – but also due to increasing demand for performance optimizations in combination with Visual Studio. And now there is also Rider, as our cross-platform IDE based on IntelliJ IDEA, which also – kind of – allows us to load ReSharper plugins if you use some magic involving bits of JVM, Kotlin, and Gradle. Sigh… Let’s get over the technology bingo!

One template to rule them all

We want you to get started quickly with writing plugins in both ReSharper and Rider, and the resharper-rider-plugin template will do just that! It is a Work-In-Progress, so any feedback is welcome. The template can be downloaded from the release page and installed using the dotnet CLI.

It is recommended to also use the dotnet CLI for unpacking the template. For instance, call dotnet new resharper-rider-plugin --name AwesomePlugin. This will unpack not just a project, but a full solution containing all relevant files for targeting ReSharper and Rider:

All relevant files for developing a ReSharper and Rider plugin

The convenience of this template is that it also ships with run configurations to test your plugin with a single click, in either Rider or Visual Studio:

Run configurations for VisualStudio and Rider (Win/Linux)

Rider plugins can have two parts, a ReSharper part dealing with source code (like C# code analysis and refactorings), and an optional Rider part for custom UIs and other IntelliJ platform related features.

These two parts run in separate processes, and can communicate with each other using a custom protocol. The Generate protocol run configuration helps to integrate into this protocol easily. A sample protocol extension is pre-generated in the protocol directory. You can find more background in the article Building a .NET IDE with JetBrains Rider written by Maarten Balliauw and Chris Woodruff.

Now, just try executing one of the Rider or Visual Studio configurations, and your plugin will be shown in an experimental instance. By default, the template ships with samples for code inspections and quick-fixes. Can you spot what they do?

Running a Rider plugin in an experimental instance

So what can my plugin do?

As an experienced ReSharper or Rider user, you probably know about common features like code inspections, quick-fixes, or context-actions. Our developer guides for the ReSharper SDK and the IntelliJ SDK are good resources to follow up on more advanced topics.

Nevertheless, the whole platform of ReSharper, Rider, and IDEA is one big open SDK and pretty much everything is extensible. That also results in the fact that the developer guides will probably never be able to cover all the possibilities.

A good way for getting inspired is to go straight to the JetBrains Plugins Repository (Rider) or the ReSharper Plugins Repository and look at some other plugins. Currently, there are around 50 plugins for ReSharper and 1200 plugins for Rider available. Read again, that number is not a typo!

Many plugins are open-source – looking at their repositories will give you some more views on how things can be done. Some of the open-source plugins are maintained by JetBrains employees and illustrate how common features are implemented while following best practices. The resharper-unity and fsharp-support plugins are good resources for a variety of applications.

Help! I need somebody!

As already mentioned, covering the entire SDK is almost impossible. So we would like to encourage you to approach us directly if you have questions. We recently started an internal Slack channel that allows you to get together with us and other developers to exchange ideas, and seek for help. Drop either Kirill Skrygan or me a message to get invited.

This entry was posted in How-To's. Bookmark the permalink.

3 Responses to Writing plugins for ReSharper and Rider

  1. Pingback: Dew Drop – February 14, 2019 (#2899) | Morning Dew

  2. Writing ReSharper plugins is now more pain than ever.
    Previously (for VS2015 as I was writing my plugin then; I’m porting it for VS2017 now) it was way easier as I just could press F5 key and it was automatically deployed into the test version of VS so I could easily test it (and probably even edit-and-continue, not sure about this).
    Now it’s way harder and practically, it’s broken:
    1. It’s required to manually install ReSharper into a special VS hive.
    2. It’s required to manually pack the plugin into a NuGet package and setup ReSharper to use the path where this NuGet package is located. Then launch the VS from test hive and install the ReSharper plugin there.
    3. It’s possible to setup C# project for ReSharper plugin to deploy updated binaries into ReSharper installation folder (for the test hive). Then on F5 build, it will deploy the updated DLL – but for some reason, it doesn’t deploy PDB file (which is necessary for debugging). So it’s easier to manually copy DLL and PDB files.

    Overall it takes way more effort to set up and still doesn’t provide the same straightforward experience I had writing ReSharper plugins for VS2015.

    I could also note that the documentation is severely lacking (most topics are still not even written and others are too brief), there are not enough samples (at least we have Unity ReSharper plugin to use as a reference for some features – though it’s not a great example as it’s quite a bloated project), and plugin API overall (Psi in particular) was not evolved for more than a decade. It’s the same old/legacy and painful API. Roslyn syntax analysis API is making a bit more sense to me.

Leave a Reply

Your email address will not be published. Required fields are marked *