ReSharper extension support

Bump!
How will JetBrains approach this? When writing a plugin for intentions, quick actions and PSI related stuff in Resharper/Rider: Will we use the IntelliJ Plugin SDK? Or will we continue to use the Resharper SDK for this?

Extensions for Rider are a bit of an interesting hybrid mix, and still very much a work in progress right now.

Rider supports standalone IntelliJ plugins, such as IdeaVim, or the REST test client, or database tools - anything that doesn't require C# language support can be a pure IntelliJ plugin.

But anything that does require knowledge of C# - inspections, quick fixes, refactorings, etc. - needs to live in the ReSharper process, as a fairly standard ReSharper plugin. These plugins can have a UI, as long as that UI is already provided by Rider/ReSharper - various editor highlight types, alt+enter menu, settings pages, etc.

If a ReSharper backend plugin requires a custom UI, for example, a dialog for a refactoring, then that UI must be written in IntelliJ (Rider is a cross platform IDE after all). This requires some inter process communication between the IntelliJ front end and the ReSharper back end, in order to a) display the UI and b) coordinate values. There isn't anything in the SDK to help with this right now. The plan is to extend Rider's own protocol (a hierarchical, observable/reactive view model shared between front end and back end processes) so plugins can use it. We're still working on this part. 

That leaves versioning and packaging.

Versioning is a bit tricky. Right now, Rider 2017.1 is based on a branch of ReSharper 2017.1. ReSharper 2017.2 has already been released, but Rider 2017.2 hasn't yet started its EAP preview program. We're working on synchronising the schedule, and working on the same branch. Once that happens, hopefully, we'll be able to (mostly) use the same binaries for Rider and ReSharper plugins.

Right now, you can build a ReSharper extension that targets Rider 2017.1, using the JetBrains.Rider.SDK nuget package. This is a superset of the ReSharper SDK, which contains a number of APIs that make sense for Rider, but not for ReSharper (e.g. code folding and syntax highlighting, which is handled by Visual Studio in ReSharper). It's also a different set of versions to the ReSharper SDK (the Rider branch).

If you have a ReSharper extension already, you can retarget it to Rider by replacing JetBrains.ReSharper.SDK with JetBrains.Rider.SDK. There will be a few incompatibilities (renamed namespaces, different overloads, nothing too scary) and it should work. You can do this with multiple .csproj files in the same folder (we're doing this with the Unity support, that started life as a ReSharper plugin and is now a bundled Rider plugin).

The other complication is packaging. ReSharper plugins are nuget packages, while IntelliJ plugins are a different kind of zip file, containing the Java/Kotlin classes and some metadata. For Rider, the ReSharper backend plugin .nupkg is actually bundled into this zip file. All of which means we can't share ReSharper and Rider plugins - they're different versions and the packaging is also different. We have some ideas here - perhaps we could automatically wrap ReSharper plugins to make it easy to consume existing plugins.

There are also some plans internally to make some C# related APIs available to the IntelliJ front end. I don't have more information to share with this right now.

Hey Matt,

thank you so much for this in-depth look of the current status. I am eager to see how you will solve this ;). Keep up the good work. Rider is awesome and our complete team has happily switched to it for Unity3d development. 

We will try to fill our plugin needs with compiling against the JetBrains.Rider.SDK package.

Cool. Let me know how you get on, or if you need any help.