ReSharper Ultimate 2018.1 Early Access Program kicks off

A month ago we released ReSharper Ultimate 2017.3.2 with lots of fixes. We didn’t waste any time and worked hard this month to prepare something new for you again. Today we open the ReSharper Ultimate 2018.1 Early Access Program.

ReSharper Ultimate 2018.1 Early Access Program kicks off

Here is a list of notable changes you may observe after installing the first EAP build:

  • Comment position on the Comment code action now depends on the setting Don’t indent comments started at first column.
  • Pressing Enter inside a line comment now splits a single comment into two comments.
  • Exporting from the Inspection Results window respects the selected filters.
  • Find code dependent on module adds support for binary references.
  • Promise classes are now correctly resolved in TypeScript projects.
  • Several performance fixes.
  • Lots of fixes in code analysis (RSRP-467698, RSRP-467710, RSRP-468333, RSRP-429534).
  • ReSharper C++ adds Debug step filters to specify functions, which should be automatically stepped over during debugging. It also adds a new typing assist to remove trailing whitespaces on Enter, and a new inspection to find usages of deleted functions.
  • dotMemory now displays virtual collectible references as Collectible instead of Unresolved.
  • dotPeek adds support for the decompilation of dictionary initializers and null-conditional operators. It has also learned to show the metadata subtree (headers / directories) for unsupported files and file description for an assembly in the Properties toolwindow.

For a full list of issues fixed in the first EAP build, please refer to EAP notes for ReSharper and ReSharper C++.

Download ReSharper 2018.1 EAP now and give it a try!

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

43 Responses to ReSharper Ultimate 2018.1 Early Access Program kicks off

  1. Dylan says:

    Literally the only thing that you should be focussing on is performance and memory consumption with VS. Using R# with latest VS version is incredibly painful and laggy, and there is no news anywhere on when this will get better. Concern #1! Grab Microsoft, if you need to, and get them to get their house in order.

    • hypeartist says:

      I second that! The performance is awful. All the nice features Resharper offers are just being neglected by the poor experience caused by its (Resharper’s) “heavyness”.

    • I am with 32GB DDR4 RAM and Inter Core i7 8700k and ReSharper is still slow.

      • Oddbjørn Bakke says:

        I would guess Visual Studio being 32bit, that the speed of memory and disk is more important than the size.

        Using ReSharper on a older computer with U-type Intel CPU, HDD, and 8GB of slow RAM… and with all kinds of corporate bloatware is just horrible. Would be nice if JetBrains gave their developers similar computers to work on.
        Luckly now I’m on a 7700HQ and a 8700K machine, and R# works ok.

        +1 for performance

    • Daniel Kaufmann says:


    • Jeff Chen says:

      I have created this issue for ReSharper team. They said that they are working on ‘ReSharper out of process’, but it takes time.

      RSRP-468407 High memory usage

    • Chris says:

      +1 for performance/memory consumption. R# gets at the edge of being useful for large solutions as more and more features are added to VS out of the box. I have to disable R# when I load our large main/all solution for performance reasons. Can only use it when working on smaller sub-parts. I like the option of being able to turn R# completely off in the options.

      As a workaround, I’d like to have an option to turn R# on/off on a per-solution basis.

    • Alexander Kurakin says:

      @Dilan We are focusing on performance and memory usage in every single release. However, unfortunately, there is no much we can do here to improve the behavior significantly. Right now, the principal causes of the performance problem we see in the performance snapshots are Roslyn and GC. We asked MS about providing a way to disable Roslyn entirely or convert Visual Studio process to x64. But nobody cares. Then we added Performance Guide which a bit but increase the overall performance in some cases.

      How do you expect JetBrains can grab Microsoft and dictate our’s terms? I don’t think there is anyone or anything which might influence MS to change the way they go.

      Some time ago we started working on moving ReSharper out-of-process, which will remove all restrictions we currently have in devenv process ReSharper now runs inside. We tried it in Rider, and it is working excellent. But I can’t provide any ETA since we have lots of stuff to do before we can present anything you can try.

      Anyway, my apologies for the performance and memory issues ReSharper caused.

      • Dylan says:

        Noted. But at the end of the day this is your product and you need to do everything in your power to make sure that your customers are happy with it. Functionality wise R# is great and I have been using it since version 3. But the performance drain is becoming too much even on powerful hardware, and your customers keep on telling you about this (just check Twitter) and constantly nothing seems to be done. Whether MS will listen to you or not is not my concern. I’m glad you’ve given us a slight hint that something good is coming in the pipeline, but note that every version you release without significant perf improvements is another few months of terrible productivity and with your customers knowing that this is R#’s fault.

        • Alexander Kurakin says:

          We definitely understand what our customers feel and indeed, for them, it does not matter whose this fault exactly is. In my message above I’ve just wanted to share with you where we are now. We do our best to bring out R# out-of-process as soon as possible.

      • Pete says:

        Do you have a GitHub issue requesting them to give you/us a way to disable Roslyn? Something we can vote on? Thanks.

      • Erdogan says:


        I’ve been trying MS to create a 64bit version of VS for years. They’ve always evaded subject. I see their point, “IDE is 32 but it works for everything, so do not use anything other than ide unless it is absolutely necessary”.

        Now they have “VS Code” as an IDE. It is good but it is not VS. It is not even close to VS + R#, but it is lite and multi-platform and everything VS is not.

        Problems with VS is not limited to R#, it just causes them to appear faster.I had used 4G enabler on devenv.exe for R# to work more efficiently. Starting with 2017, MS itself compiles IDE with flag already on.
        They know the problem, but instead of fixing it, they just use band-aid. My guess is VS team is will drop VS and continue with “Code”.

        On my computer with 16 GB RAM, VS + R# trial uses about 1.5 GB of memory for 750 kloc project. 6 GB of RAM is free and VS gives out-of-memory errors. In theory 500 MB more is available to VS, but it gives error. My two cents says it is memory fragmentation, and it cannot be solved in process.

        I’m waiting for an out-ot-process R#, since it is most efficient way to solve problem and it makes R# independent of VS. It would be nice to work with Sublime + R#. A nice benefit of out-ot-process would be tat it would shield R# from IDE crashes. It would just go-on working as usual.

      • Erik says:

        Rider performance is excellent compared to VS, if the same level of responsiveness could be brought to VS I would be very happy indeed!

      • Juan Garcia says:

        To be honest. I know VS 2017 is being developed in India and not by too senior developers. I do not think make the process x64 and performance issues it is the priority. They want to make VS to crash the less possible. VS Needs a total rebuild by very senior teams if Microsoft still has them and they did not fly to Google.

    • Colin says:


      I’ve been using ReSharper for many years but am considering making this the last – VS has improved a lot, and the performance impact of ReSharper is *still* staggeringly bad (even on my 64GB, Xeon E3, SSD monster!) – if anything, it’s only got worse over time.

      ReSharper for Visual Studio Code – now that I would gladly switch to!

    • Jeremy Schaab says:

      +1 – Performance Hog in large projects. I never can tell if the exclude files even works because the building cache window always seems to include files I said to exclude.

    • GreenMoose says:

      +1, for the sake of argument I tried doing the same amount of work with RS enabled and suspended when devenv.exe had been up running for a while (RS reported 1.2GB memory usage in the status bar).
      When RS is enabled I every other code line need to wait for IDE to become responsive. (I feel it is even worse with javascript editing).

      I quickly feel ReSharper gets in my way of feeling productive on an every day basis :(

      Screencast with RS enabled (2m09s):
      Same amount of coding with RS suspended, same devenv.exe process (1m31s):

    • I totally agree! Please, focus on improving performance.

  2. Manuel says:

    I am missing the 2018.1.0-eap1 SDK!?
    Our plugins doesn’t work anymore :-(

  3. Simon Tipper says:

    Disappointing not to see any mention of dotCover and improving the horrific performance issues.

    • Alexander Kurakin says:

      @Simon Do you expect to hear some specific about dotCover? As for the performance issues – have you collected a performance snapshot of any of them and sent it to us to give us a chance to find out a cause of the issue?

  4. Brandon Pen says:

    PERFORMANCE JetBrains! PERFORMANCE! I absolutely LOVE ReSharper, unfortunately I dislike having to pick and choose between one or two features at a time.

    You should only ever notice a tool like ReSharper once it’s gone or uninstalled, not every single time you press a key. I sometimes joke that using ReSharper is like trying to code when your remote VM is on Mars; it takes 20 minutes for the signal to get there.

    Focus on making us forget that we’re even using ReSharper, so that when we are confronted with a clean installation of Visual Studio we are left dumbfounded and unable to function in our daily programming routine, instead of being constantly reminded that the reason Visual Studio is incredibly slow and sometimes impossible to use is due to the fact that we are using a (albeit powerful) productivity killing monstrosity.

  5. Lucas Trzesniewski says:

    I was really hoping for C# 7.2 support in this version… Right now I can’t use features like ref struct for instance, because ReSharper doesn’t like that at all.
    Can you give an estimate for when this will be available?

    • Alexander Shvedov says:

      Hi. R# 2018.1 already contains support for byref-like structs (parsing, error inspections, reading byreflike type flag from metadata). Can you please report particular issues you experience with ref structs?

      Initial C# 7.2 support is scheduled to 2018.1 RTM and we are actively developing it. Non-trailing named arguments and ‘private protected’ modifier features are ready and will be available in upcoming EAPs, byref-like struct support seems to be finished except some really complex cases of return safety analysis, leading literal separators in numeric literals are coming soon. In parameters + ref readonly returns/locals + readonly structs are the most lagging behind, simply because of the amount of code and features R# has (for perspective, we have to review all 968 checks of parameter kind to fill ‘in’ parameters handling). Parsing of such constructs is already working fine, you can report the most annoying issues so we can fix them first and deliver implementation in upcoming EAPs faster.


      • Lucas Trzesniewski says:

        Thanks for the heads up! It’s good to know it’s planned for the RTM!

        By saying “Right now”, I was talking about 2017.3, and I haven’t tested the 2018.1 EAP yet as the announcement doesn’t mention C# 7.2 support at all.

        I don’t have a lot of code that uses C# 7.2 features yet mostly because R# 2017.3 got in the way. I mainly added “readonly ref” to an existing struct and “in” to its extension methods, but I have lots of code that uses that struct.
        I’ll be sure to test the EAP and report the most annoying issues.

      • Lucas Trzesniewski says:

        OK so I’ve tested the EAP and the most annoying issue for me is the lack of support for “in” parameters, which is not surprising given what you’ve said above. I don’t think I should file an issue in the tracker given that the feature is in active development, but here are some observations:

        – I get plenty of errors like “Cannot make ‘in’ parameter of type ‘XXX'” (where XXX is a valid struct for “in”)
        – Implicit “in” on call sites is not supported (you can’t omit the “in” keyword when calling a method with an “in” parameter). The error is: “Argument is ‘value’ while parameter is declared as ‘in'”.
        – Overload resolution doesn’t like “in” parameters either, even though all candidates have the same “in” parameter and only differ on a second unrelated and non-“in” parameter.

        I’m pretty sure there’s nothing you didn’t already know in there :)

  6. Gordon says:

    Turn CodeLens off if you have it on.

  7. horeaper says:

    Still no ETA on C# 7.2 support?

    • Alexander Shvedov says:

      ETA is 2018.1 RTM, while particular features will be available in upcoming EAPs as soon as possible. What are the most annoying issues you experience with current EAP? Most of the new constructs should at least parse and code-complete fine.

  8. David Pokluda says:

    Performance of this EAP build is really bad. I was forced to uninstall and install latest stable version.

  9. NN says:

    Isn’t ” Debug step filters” same feature that VS has: natstepfilter

  10. mdouglas says:

    Can you please confirm if C++/CLI support will be included in 2018.1 RTM? If not, please could you let us know when this feature will be included.

    • Igor Akhmetov says:

      Sorry, C++/CLI won’t be in 2018.1 RTM. Our target is 2018.2 – we’re finishing support of the language itself, but still need to update different ReSharper features (e.g. find usages/rename) to work in both C++ and managed languages.

  11. Caleb D says:

    Resharper performance degradation since v9 has been noticeable. Some R# releases seem to be better than others. When I disable R# and use vanilla VS, I’m amazed at how responsive it feels. HP Zbook 15 G3 with ssd, quad i7, 32GB ram.

    We have ~200 projects in a solution (large framework). I can usually outrun R# intellisense with my typing (60wpm).

  12. Magnus Persson says:

    After “upgrading” to ReSharper 2018.1 Visual studio becomes completely unusable. I must ask do you (JetBrains) even use ReSharper yourselves? I really like the features of ReSharper but having to wait several seconds for the characters I write to show up is just not working.

  13. Alex says:

    I upgraded from 2017.x to 2018.1. Attention do not do this! since the update resharper is unusable. Huge performance drops after saving and while editing files. I did every performance optimization which is given by different guides from microsoft and jetbrains. I am said that it gets worse and worse and i am soon turning my face away from jetbrains and throwing resharper into garbage. Rider is no solution for me. This IDE doesn’t provide the functionality i want and the design I want.

Leave a Reply

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