ReSharper 2020.1 Roadmap

We recently posted our roadmap for ReSharper C++ 2020.1, as well as our roadmap for Rider 2020.1. Since we’ll be starting our Early Access Previews very soon, we’d also like to share our roadmap for ReSharper 2020.1. We’ll also be talking about where we are with moving ReSharper out of process (although see this post for more details).

Here are the top priorities that we’re currently working on. Some of these are themes for work that will see us through 2020, and not just for the 2020.1 release. So some of the things mentioned here won’t necessarily make it into ReSharper 2020.1.

  • Modern C# – a major part of the work we’ve got planned for this release, and this year, is support for modern C# – not just C# 8, but also looking forward to C# 9. There are a lot of new, big features coming to the language, and we’ll be updating ReSharper to take full advantage of these. Features such as default interface implementations, nullable reference types and pattern matching are welcome additions to C# 8, and C# 9 will potentially introduce record types and discriminated unions. As usual, ReSharper will have a ton of inspections and quick fixes to help you learn new features and migrate.We also need to teach existing ReSharper features about these new language features. For example, nullable reference types need to interact correctly with all our existing inspections and quick fixes, as well as the heuristics that ReSharper Build uses to speed up your compile times. We’ll also be updating the dotPeek decompiler, built into ReSharper, to understand nullable reference types and named tuples, and much more.
  • Distributed caches – not for the first time, we’re going to be adding a feature to ReSharper that started life as an internal hackathon project. ReSharper builds a number of caches based on the code in your solution, which it can use to speed up navigation or analysis. Once created, the caches are cheaply and incrementally kept up to date, but we’d like to reduce the initial creation time by downloading pre-built caches from a server, or from colleagues. This won’t be complete for 2020.1, as it requires a number of changes that we’ll be working on throughout 2020, such as updating the file format to make the data more easily shared on a file by file basis.
  • Out of processif you haven’t already heard, we’ve been working on a long term plan to move the majority of ReSharper’s language processing – analysis, inspections, quick fixes, refactorings, etc. – to run outside of the Visual Studio process. We won’t have anything visible as part of ReSharper 2020.1, but there has been a lot of work done under the covers.We’ve got a separate post which goes into more depth on where we are right now, but the short answer is that we’re now able to run ReSharper’s language parsing, analysis and quick fixes out of process. This still leaves a lot to do (e.g. refactorings and all menu item actions!), but this is a significant milestone. Read the post for more details.
  • Unit testing – we have a number of features that we’re working on for 2020.1 related to testing, such as improving test discovery for .NET Core projects, using xunit.net’s display name instead of method name and new inspections and quick fixes for nunit tests. We’ll also be introducing support for Karma to help test your JavaScript code.

Of course, this isn’t everything we’re working on. There are lots of other features and fixes that don’t fit neatly into the themes above, such as removing “suspicious” web files from analysis – files that we can heuristically identify as generated, output or tests that aren’t required to work with your project, e.g. files in a dist folder under node_modules. We’ll also have some updates to code style and the code formatter, as well as more work on support for localisation and inlay hints for XAML. And we’re always working on performance features, from fixes for particular scenarios, to larger architectural updates.

Speaking of which, make sure you click here for the companion post to see where we are with out of process.

Let us know what you think of the plans. If you think we’ve missed anything, please suggest a feature in our issue tracker, or upvote any existing issues. The previews will be starting soon – we’re looking forward to your feedback!

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

22 Responses to ReSharper 2020.1 Roadmap

  1. Daniel says:

    – Javascript code inside .cshtml files is not parsed/analized/indexed.
    I can’t use Alt+\ (Go to File Member) to navigate inside a file.

    – I have a viewModel.getFormToValidate function, however *getFormToValidate* is highlighted in red (as though it’s missing/not declared).

    I’m using the latest Rider, on Windows 10 Pro x64.
    I gave up on Visual Studio and I don’t regret it, but these issues are becoming annoying.

  2. Gabriel B says:

    The link to the companion post seems broken. It points to the right title, but the slug of the post retained its previous title (I assume it was changed).

    https://blog.jetbrains.com/dotnet/2020/02/24/update-on-running-resharper-out-of-process/ is the correct URL.

  3. Karen Tazayan says:

    What about F#? Any new features?

    • Alexander Kurakin says:

      ReSharper does not support F#, but Rider does. So, it’s better to ask it here https://blog.jetbrains.com/dotnet/2020/02/19/rider-2020-1-roadmap/

      • C. Shea says:

        Any plans to support F# in ReSharper? After all, it’s a supported .NET laungage in Visual Studio. Since I already pay for Visual Studio and ReSharper Ultimate, I’m most certainly NOT going to buy a license for Rider for a language already supported by Visual Studio.

        • Matt Ellis says:

          No plans currently. There’s simply not enough memory space inside the 32 bit Visual Studio process to accommodate another instance of the F# Compiler Services (FCS) parsing and running type inferencing on your solution.

          We can’t reuse the existing FCS running inside Visual Studio because we use a custom version that has changes to enable integration with ReSharper’s caching and refactorings, allowing us to do cross language references and renames, etc. While we do push the changes upstream, we have no guarantee of when those changes ship in Visual Studio.

          We’ll review this once we have ReSharper running out of process, when we can host FCS inside a 64 bit process, like we do with Rider.

          And we hear what you’re saying about licensing. We are looking at simplifying things here, but in the meantime, why don’t you give Rider a go with your solution? It might be able to replace Visual Studio completely! Give the trial a go, or download the EAP preview builds, and do let us know if you need an extended trial.

  4. ItIs2020 says:

    Will there be new features though? Adding more of c#8/9 is not quite a new feature.
    I would love to be able to define custom colours for methods for example.

  5. Erwin Beckers says:

    How about performance improvements ? I love resharper but i regularly get freezes in VS2019 which can lead up to 5-6 seconds where i cannot type anything and resharper is busy doing something in the background. VS2019 shows the yellow bar on top that resharper is causing these issues. Got this on multiple pc’s and as soon as i disable the resharper extension these issues go away.. but offcourse.. i dont want to do that

    • Mark says:

      Erwin, this is what the out-of-process change is meant to solve. It is just unfortunate that it is a HUGE change. But at least they are working on it.

    • Matt Ellis says:

      Sorry about this Erwin. We are definitely working on performance improvements too. We’re aware of the yellow bar during startup, and there is work underway to address this. The main issue here is how we create our components. Currently, because the object graph eventually requires access to COM APIs, we do this on the UI thread, although we do pump messages so it shouldn’t be completely unresponsive. We’ve been working on an audit of all of our components so that we can introduce lazy instantiation and initialisation of components, remove the COM access as much as possible and also move all of this off the UI thread (with some necessary sync points for COM access just to make things extra tricky). While we’ve made good progress on this, it’s still experimental and internal, and doesn’t look like it will make it into 2020.1.

      Other scenarios should perform well, and if you’re seeing the yellow bar or freezes during normal usage or typing, then we’d love to investigate further. You can capture a performance profile directly from ReSharper and automatically send it to us, or we’d be happy to take part in Skype or TeamViewer or other remote session to investigate.

      • Lieven Bogaert says:

        I really hope this will be finished soon. In my case, I had to disable Resharper entirely for my (older) AngularJS/Typescript projects that I need to maintain. VS would freeze up from a few seconds to a few minutes after just typing a single letter and occasionally crash entirely.
        For newer Angular/typescript projects I even switched to VS Code for this exact reason…

  6. Adam Pluciński says:

    Hi,

    could you please consider also support for Jest?
    https://www.npmtrends.com/jest-vs-karma

    Thanks

    Adam

  7. brian mackay says:

    Any ETA on this release? It is now Q2.

    • Matt Ellis says:

      Hi, Brian. The release is still on schedule, due in the second half of April. We have three releases a year, and so we’re not tied to quarters.

      • brian mackay says:

        Thanks! Looking forward to performance improvements. I still believe.

        …I hope it’s substantial though. I hired a new developer and I decided I can’t make her deal with the performance problems. I can’t help thinking about other options, like Roslynator, etc… It is pretty bad.

Leave a Reply

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