Dotnet logo

.NET Tools

Essential productivity kit for .NET and game developers

.NET Tools How-To's Roadmap

Rider 2021.1 Roadmap

In this post, we’d like to share our plans for Rider 2021.1 and find out what we can do next to improve your development experience. Your feedback is always welcome!
The following is a list of our priorities for the next release cycle of 2021.1. Note that these are features we’re working on – as opposed to features scheduled for delivery – and that some of these might be delayed until a later version.

Update: Apologies! We missed the Unity section off the original post. It’s back now!

  • Code With Me: Last year collaborative coding (Code With Me) was added to our other IDEs. Since Rider has a very special architecture with a JVM frontend and a .NET backend, it requires additional steps to be properly integrated. We hope to bring CWM to the Rider 2021.1 release.
  • Welcome Screen: We’ll continue to improve our Welcome Screen to help with another common workflow, which is to debug running processes. This will allow you to open Rider and attach to a process without having to create or open a solution or project.
  • Performance: Some users might be familiar waiting a while for the solution explorer to show the structure of a solution… We are working to make the explorer load instantly without disrupting developers’ workflows, and to allow them to immediately browse their code. As always, we will look out for any opportunity to improve the performance.
  • Problems View: As developers we deal with a lot of different issues every day. In order to help our users keep track of them, we will adopt the Problems View from IntelliJ IDEA to have a single view for all problems such as missing environment components, NuGet package errors, and code inspection issues for the current file and the whole solution (solution-wide analysis).
  • ML Code Completion: As an improvement to our standard ranking in code completion, machine learning-based ranking can use data gathered anonymously during EAPs to provide results with better context relevance. Other languages are already supported in our IntelliJ IDE family, and we’re planning to use that same engine for C# ML completion in Rider as well.
  • Debugger: We are planning to introduce a quick toggle for breaking on unhandled exceptions (exception breakpoints) and stepping into external source code – a task that usually involves navigating through dialogs.
  • Localization: A new localization infrastructure to support additional languages inside Rider and all other IntellIJ-based IDEs. It’s unlikely to appear in the next release, but we’re starting our efforts on this.
  • ASP.NET Scaffolding: Adding new functionality to our web projects involves a lot of different entities with a lot of boilerplate code at the beginning. The aspnet-codegenerator is a very useful tool to scaffold controllers, identities, views, and others. We’re going to integrate the generator in our Add Item infrastructure and add a UI for easy configuration with all the necessary options for code generation.
  • WPF Preview: Reworked UI/UX with support for custom markups, design time attributes, templates, third-party controls, and resources from separate files and referenced assemblies. This also includes navigation to the corresponding tag when clicking elements in the preview and selection when elements are moved.
  • WinForms: We’ll be focusing on the toolbox to make it feel more like Rider’s other UIs. That means it will provide better filtering and grouping. We are also going to address some issues related to DevExpress components.
  • F# Support: More refactorings and quick-fixes, most notably an inline var refactoring and additional cases for the import quick-fix. We are also planning to move type providers out of process so that their runtime matches the one used during the build process.
  • Unity: A few new features, several fixes and a bit of under the hood refactoring this time round. Rider already tells you if a method is performance critical or in a Burst context, and now we’ll show you why – showing the call tree back up to an Update method or the root of the Burst compiled context. We’ll get debugging support for SerializedObject and SerializedProperty, Find Usages in animation assets and we’re looking at supporting code coverage for play mode unit tests, as well as a few more little things.

We hope there is something interesting for you, too. Plenty of other, smaller features may get implemented along the way. Feel free to comment below, submit a new feature request in our issue tracker if we’ve missed something, or upvote any existing requests to let us know they are important to you. We’re looking forward to your feedback!

image description