Rider – the story so far

Last time, we had a look at what was new in the June EAP of Rider, our .NET IDE.

This time, we’re going to go back to the beginning and have a look at some of the interesting features we’ve added during the EAP so far.

This includes:

  • Core IDE features
  • NuGet
  • File Structure
  • Solution Wide Analysis

Core IDE features

Rider is a .NET IDE, and as such, requires a certain set of functionality, such as opening and creating projects, build and debug, and of course, an excellent editing and code navigation experience.

Rider supports opening Visual Studio solutions and .csproj based projects. It also supports .NET Core applications, as long they also have a solution and .xproj files (remember, .NET Core tooling is changing back to MSBuild based .csproj files. Rider will support this, too).

And of course, it allows creating projects, too, with project templates that can create executables, class libraries and .NET Core projects.

Project templates

But Rider would be nothing if it didn’t have a good editing experience. And here, Rider takes full advantage of both its ReSharper and IntelliJ heritage, to provide all the functionality that you know and expect from a JetBrains IDE: complete statement, auto-completing brackets, tooltips and parameter info, live templates, and of course lightning fast code completion, either when you type ., or automatically, in context, like completing a type name after new.

Code completion

Rider also includes very rich navigation, making use of IntelliJ’s Search Everywhere feature to search for classes, symbols, or files, even searching for IDE actions and settings. In addition, you can Ctrl+click to go to definitions, go to file member, and of course use the Navigate To context menu to move up and down a class hierarchy or use other navigation options:

Navigate To context menu

And who can live without Find Usages?

Find Usages tool window

Rider has been designed to make the most of the investment we’ve put into ReSharper for the past 10+ years. Rider uses ReSharper as an out of process language server, so any functionality we add to ReSharper can be used in Rider (and any functionality we add for Rider can also be used by ReSharper).

The protocol we’ve designed for the Rider frontend to talk to the ReSharper language server is very lightweight, two way and asynchronous. On top of that, the data we’re sending between the two processes is designed to also be very lightweight – little more than “view models”.

For example, every advanced IDE needs to display inspection highlights – “squigglies”. 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.

This means that Rider immediately gets access to all of ReSharper’s over 2000 inspections.

Inspections with tooltips

And what would a JetBrains IDE be without Alt+Enter?

Everybody’s favourite keyboard shortcut is there, ready to safely rewrite code to apply quick-fixes to all of those inspections, or perform context specific actions like converting a string literal to string interpolation, or even marking it as a regular expression!

Alt Enter context menu

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.

Rename dialog

NuGet Support

NuGet has changed the way we consume dependencies in a .NET project – referencing packages is a lot better than manually downloading libraries, adding them to a libs folder and checking them into source control.

So of course, Rider has to support NuGet. And of course we wanted to sprinkle a little JetBrains magic on it.

The idea behind our implementation is to be as fast as possible. When you search for a package, we return cached search results, so commonly used packages are available instantly. But we’re also updating the results in the background, so any new packages, or new versions, are added asynchronously.

The UI might be a little different to what you’re used to. The NuGet tool window is split three sections. The first is a view of the solution and project hierarchies, the second lists packages, and the third shows package details.

Selecting a node in the solution hierarchy lists the packages that are already installed, and provides a text box to search for packages to install. This list also shows when a package has an update available.

Clicking on one of these packages shows details in the final section of the window. This shows the package description, authors, license, project URL and so on. It also lists the available versions in a drop down – selecting one of these and clicking Apply will install, update or rollback to that version. Clicking the Remove button will of course remove the package.

And finally, the Restore button next to the solution hierarchy will restore all packages, downloading any that are missing.

NuGet tool window

Along the top of the tool window, you’ll notice some tabs:

  • Packages – the default view, for managing packages.
  • Sources lists all of the config files that NuGet is using to figure out what package sources are available. Rider will show what the effective list of sources are, and clicking on the config file will open it up in the editor.
  • Options allows configuring various aspects of Rider’s NuGet support, such as whether the search should include pre-release packages, and the default behaviour for resolving loosely specified dependencies.
  • Log shows the output of any NuGet operations, including errors and conflicts.

File Structure

The File Structure window shows an outline of the current file in the editor. So for a C# file, it will show classes, and under each class is a list of class members – methods, properties, fields, etc. Double clicking one of these will navigate the editor to the appropriate location in the source, and if you toggle the Autoscroll from source toolbar button, whenever you navigate around in the editor, the matching type member will be highlighted.

File Structure tool window

See the title of the tool window tab docked to the side of the window? 7: Structure – the “7” means that you can quickly get to the tool window by pressing Alt+7. This works for any tool window that has a number in front.

Solution Wide Analysis

Another feature that Rider has brought over from ReSharper is Solution Wide Analysis. When enabled, ReSharper will analyse all files in a solution, rather than just open files.

This gives ReSharper a much better view of your solution, which it can use to power a number of features. For example, it tracks cross-file symbol usage, so it can highlight public classes or methods that aren’t used in any file. It also maintains a list of errors in all files across the solution, and uses the cross-file usage information to intelligently and efficiently rescan only
affected files to keep the list up-to-date as you type.

The Errors in solution tool window in Rider will display the list of errors in your files, grouped by file. Double-clicking on an error will take you straight there, while using the Next error action in the editor will cycle through all errors in the list, across all files.

Errors in solution tool window

And just like in ReSharper, there is a little icon in the bottom right of the status bar, showing if the solution has errors or not, allowing you to use the feature without having to have the tool window open. Clicking the number of errors cycles through them, while clicking the icon will open a small context menu to get quick access to useful features.

Errors in solution status bar icon

Solution Wide Analysis is disabled by default. Scanning all of the files in a solution obviously has an impact on resource usage, and we would rather you opt in to this behaviour. For most real world solutions, the disk-based caches happily handle the extra data required, and once the initial scan of all files is done, the cross-file usage data makes keeping the list of errors up-to-date very efficient.

And since Rider uses ReSharper as an out of process backend language server, ReSharper has much more headroom to allocate and use memory that won’t affect other aspects of the IDE. So give Solution Wide Analysis a go on your solution!

Rider is still in private EAP, although we are getting ready for a public preview. If you’d like to give it a go right now, please head over to the signup page, and we’ll send you a download link.

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

28 Responses to Rider – the story so far

  1. Mike-EEE says:

    Man it is great to see the work here. I would love, LOVE, LOVE to see you completely smoke Visual Studio/MSBuild/Roslyn Build System’s mindset and provide a richer, deeper, and better quality experience around the project system, allowing developers to define/describe their projects in full serialized POCO format, which in turn takes advantage of your great tooling.

    The csproj/xproj and even project.json suffer from a long-standing problem in project description in MSFT culture, in that projects are described/defined in an arbitrary schema, which is then mapped/created to a POCO object. This is very cumbersome and difficult to work with. Conversely, when you work directly with a POCO (ala Xaml), you get intellisense/tooling built-right in as you are working directly with an, well, POCO.

    In fact, your IDE outputs and integration points (csproj/xproj) should be the result of an XSLT transform based on your POCO model. :)

    Anyways, just some thoughts. Some links to this subject are here:
    https://github.com/Microsoft/msbuild/issues/613
    https://github.com/dotnet/roslyn-project-system/issues/37

    You can see the demand/desire for this shift in thinking, and how much corresponding resistance from MSFT there is to it… maybe you can change that. :)

    • Stephen Donaghy says:

      I would much rather that Rider made use of the same project system as Visual Studio, so I can swap between IDE’s at will.

      • Mike-EEE says:

        I am suggesting 100% compatibility with VS IDE, but the “source” model for the projects is defined in Rider, and then translated as necessary to create the necessary files/artifacts that can be read by VS (or other IDEs). Basically, Rider/JB has the stronger model which then caters to the other (external) systems, if that makes sense. By default the project uses the Rider format, but a “Compatibility Mode” for other IDEs can also be implemented/utilized, as a thought.

        As long as someone… ANYONE can do away with the arcane, error-prone, and arbitrary project schema system that has been a mindsore for over a decade, that is what is important here. 😛

    • Mark Rendle says:

      If you want to define your build using a POCO, have you considered Cake?

      http://cakebuild.net/

      • Mike-EEE says:

        Not just builds, but projects, too. Everything should be defined in a POCO (schema-evident) manner rather than the labor and artifact intensive XML-mapping approach that MSFT has blindly replicated for over a decade.

        Also, I do mean *serialized* POCO and not POCO (code) POCO. :) Xaml is the best paradigm/implementation of this, and is part of the reason it is so popular. Unfortunately it has been relegated to UI components, when in fact it is a serialization engine much like JSON, except much more powerful and robust.

        And yes, Cake is cool. In fact it is discussed in the github links above. :) From my understanding is is code/C#-based and not serialized POCO. The obvious benefit of a serialized format is the designer/tooling and language-agnostic qualities that ultimately lead to lower TCO.

    • Alistair Chapman says:

      Just curious, but will you ever shut up about your theoretical XAML project system? Every .NET post I see, you’re right there fighting a battle the vast majority of .NET developers don’t agree with..

      • Mike-EEE says:

        Hahaha yeah I probably deserve that. It’s not Xaml per se, but a serialized POCO format. I mention Xaml as the closest approximation to what we’re after here, but if it’s truly POCO, you can bring any serializer (format) you wish — JSON, YAML, TOML, even INI if you prefer.

        And I wouldn’t say that a vast majority disagrees with this at all:
        https://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/9347001-improve-reboot-visual-studio-project-system

        I’m just most vocal/passionate about it (after having to deal with this filth for over a decade), and yes I do need to work on reining it back from time to time. :)

      • Roger J. Wilco says:

        I too have seen this discussion in several places and I am in support of it. The longer you have been in Visual Studio the more you will appreciate the ask. Don’t get caught up in Xaml. Having Xaml experience helps understand the request, but the core issue here is more of a particular mindset towards configuration than a specific technology/format.

        Since JetBrains has a history of understanding MS technology better than MS itself, it is smart to bring it to their table to see if ti can be done.

  2. I’d love to see ReSharper adopt the separate process model for working in Visual Studio too.

    While it has improved a bit over the years, R# is still a bit of a memory hog with large solutions. eg. It’s quite common to have to unload R# when you know you’re going to be doing something that will touch a lot of code/projects (eg. updating a solution-wide NuGet package).

    Yes, I’ve logs some bugs around this, and also tried to submit memory dumps for things like “Solution leak detected” but I think there are must be some problems with the submission tool as usually the dump upload never finishes.

    • Jura Gorohovsky says:

      David, making ReSharper out of process is our target, and the work on Rider actually helps move towards that target.

      The submission tool gets a bit messy sometimes, we’re currently trying to make it more stable.

  3. Mark says:

    I really like your tools. Would you briefly tell what would be the differences between the Rider and VS+ReSharper?

    • Jura Gorohovsky says:

      Mark, hold on: we’ll come up with a (hopefully detailed) comparison later on.

      As of now, Rider’s major benefit is that it can work under Linux and Mac OS in addition to Windows. There are also little things like Local History, multiple-cursor editing, and Go to Action that are available in Rider but not in Visual Studio, even with ReSharper.

      However there’s a lot of areas like debugging, diagnostics, emulators and designers where we still have to define how Rider stands versus Visual Studio, and reach feature parity where possible and reasonable.

  4. Pingback: Dew Drop - July 27, 2016 (#2296) - Morning Dew

  5. Pingback: Die .NET-IDE Project Rider – eine Bestandsaufnahme

  6. Dev says:

    When will Xamarin be supported? Thanks.

    • Jura Gorohovsky says:

      Yes. We hope to blog about support for Xamarin and Unity soon: how it stands now and what can be expected to improve in future.

  7. Gauthier Segay says:

    “.NET IDE” is there any hope for .NET to be a super set of C#? https://www.jetbrains.com/rider/ still mentions “C# IDE”.

  8. Luiz Arantes Sa says:

    Will Rider work with vagrant? Using .NET 4.5 on my mac would be a dream come true :)

  9. Dave Fury says:

    Will Rider include any WebStorm type functionality?

    As someone who generally splits his projects into an API and an SPA client, VS (although improving on this) really sticks the client aspect as a second class citizen – MSBuild not currently supporting async steps like Gulp processing, no real project templates for client only beyond the Web Site projects (where you need to faff with a .wpp.targets file)

    Equally, I don’t want to be flipping between IDEs, so something that can handle both aspects well would be a boon.

    • Dave, most likely it will be supported via plugins, just like any other JetBrains product. For example PyCharm, PhpStorm, RubyMine all include WebStorm functionality via plugins. It might be already supported (try searching for Gulp in plugins repo), I didn’t check myself yet.

    • Jura Gorohovsky says:

      Sergey is correct in that a lot of WebStorm type functionality will be supported via plugins. Some of them are already available, others not. (I’m guessing Gulp isn’t available at this point.)

      There’s also ReSharper functionality for web development that’s also going to be available and contribute to the final mix.

  10. William Gant says:

    I’m really excited about this, as I recently went through all my software that I use day to day, and Visual Studio + Resharper was the only item in the list that is windows-bound. I’ll still have to keep it on a VM, but I’m looking forward to coding on linux with Rider whenever it goes live.

    Heck, given the instability I’m experiencing with .net core on VS2015, I may start using it on windows first.

  11. Thomas says:

    At last! An IDE which won’t run out of memory with 20+ projects in a solution. I’m really struggling nowdays with VS+Resharper because of the 3gb limit. I expect a 64bit version of Rider.

  12. Ray Taylor says:

    Now the only one reason that stops me switching VS to Rider is the Unity3D support(something like Visual Studio Tools for Unity). My current working flow is editing code with Rider and debugging with VS…

  13. Tiemeng Liu says:

    Just tried the Dec. 19th EAP, the quality is pretty good! Looking forward the RTW/Final release. Cheer!

Leave a Reply

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