ReSharper 2020.2 Roadmap
As ever, please be aware that this list is preliminary. These are the broad areas we’re working on, and a list of our priorities, but things can change before release. With that disclaimer out of the way, let’s take a look at what’s coming!
- Out of process – we’re continuing to work on the delicate process of unpicking years of synchronous execution and API usage assumptions and replacing them with asynchronous out of process calls. We’re getting very close to having something to show, but there is still a lot to do. In this release, we’ve already got the project and code models able to run out of process, and we’re now working on moving our text editor integration out of process too. We already have interfaces to work with different versions of the Visual Studio text editor implementations which will help, but these interfaces were designed to work synchronously, in process, so it will take some work to make them properly asynchronous.
- C# 8 (and 9) – the C# language is always evolving, and ReSharper needs to evolve along with it. We’re continuing to improve support and features for nullable reference types, with extra inspections, quick fixes and context actions. But we’re also looking at other C# 8 features such as async streams, which is a fairly complex topic, and provides many opportunities for inspections and helping you rewrite your code to take advantage of these new features. ReSharper already has great support for async streams but we’re aiming to provide even more features, in particular, enable await foreach to LINQ conversion. And we’ve also got C# 9 coming, with some very interesting proposals such as records, top level programs and more improvements to pattern matching. We’ll be starting work on supporting those features when they are closer to being stable.
- Better Blazor support – we’re aiming to improve the Blazor experience with ReSharper, with better integration with Razor components relating to references, navigation, and code completion.
- Unit testing – this release will bring a new unit test runner process. We’ve always run your tests in an external process, so we can handle multiple target frameworks, as well as provide parallel execution, code coverage and so on. But for .NET Core, we’ve been using the standard “vstest” runner. This has several problems, including various performance issues, and a lack of flexibility in matching how we’ve traditionally shown tests in a tree view. So we’ve rewritten our existing test runner process from scratch, to work with all target frameworks, including .NET Core. This will give us a number of benefits, including much faster test discovery for .net core tests, full control over test hierarchies and the tree view, as well as improved support for display names and integration with TypeMock, and running Microsoft Fakes across all .NET and .NET Core frameworks. There’s even time for some UI improvements to the Unit Test Sessions tool window!
- XAML – with continued use of XAML in WPF, UWP, Xamarin and now with the introduction of MAUI (not to be confused with Maui), we’re working on XAML features, including x:Bind support, a surprisingly large feature set for a single element – completion, parameter info, create from usage quick fixes, change signature refactorings, call and value tracking participation and so on. We’re also making some nice UX improvements by adding inlay hints to the XAML editor to help understand what’s not obvious from the text.
- Inlay hints – speaking of inlay hints, we’re making some tweaks to this feature to help improve usability. We’re redesigning the options page to make it easier to configure, and if you find the hints too noisy, you’ll like the new “push to show” mode to hide the hints until you actually need to see them.
- Code cleanup – there are several features around code cleanup that we’ve got planned in this release, including improved EditorConfig integration with compiler warnings, and also running code cleanup on save.
- Accessibility – and last, but by no means least, we’ll be making some much needed accessibility improvements around the Alt+Enter menu, the completion popup, options pages and several other specific scenarios that have been provided by users.
Of course, since ReSharper is the engine for Rider, many of these features will also appear in Rider, especially the C#, Blazor, and XAML support. However, it’s important to point out that a number of these features are ReSharper only, such as the improvements to inlay hints, as well as work on the UI, UX, and accessibility of ReSharper.
This isn’t everything that we’re working on. There will be plenty of other smaller features, and we’ll be looking at fixing issues from YouTrack, including bugs and specific performance issues.
What do you think of our plans? Feel free to comment below, or to 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!