The difference however, is that instead of reimplementing ReSharper’s features on the IntellIJ Platform, which runs on the JVM, we’re using ReSharper in a headless mode, out of process, and communicating with it via a very fast custom binary protocol. As such, the backend continues to be ReSharper written in C# running on .NET or Mono, and the frontend is written in Kotlin, talking to the IntelliJ Platform’s APIs.
With Rider, these inspections are carried out by ReSharper, out of process, and the data is passed to Rider, as a “view model” – essentially a list of offsets, highlight types and tooltip text.
While the protocol allows us to reuse a lot of existing functionality, some features, such as refactoring, take a bit more work. Interestingly, a lot of the work is to create new UI for the workflows – ReSharper already knows how to rewrite your code, but it needs to know what you want to do. Which means we don’t have all of ReSharper’s refactoring support available in Rider right now. But we do support a number of refactorings, especially the most important – rename.
It seems they untied it from VS enough you are able to integrate sd with resharper.
https://blog.jetbrains.com/dotnet/2016/01/13/project-rider-a-csharp-ide/
https://blog.jetbrains.com/dotnet/2016/07/26/rider-the-story-so-far/
It seems they untied it from VS enough you are able to integrate sd with resharper.