ReSharper 8 EAP, Build 3: What’s New!

You have probably already guessed that this post is about a new set of features that has appeared in the new build of the ReSharper EAP late last week, so, without further ado, here’s what we’ve got in store for you:

Bulb Menus in Margin

In an attempt to streamline the programmer’s interaction with gutter marks and bulb pop-ups, we have added an option to merge both of these constructs into a single construct that we call an action indicator. Here’s what it looks like:

As you can see, both the gutter mark options from unit tests and the context action on that element have been merged into a single menu. The use of action indicators is an optional feature that can be found in ReSharper’s Options under Environment|Editor|Editor Appearance:

Option #2 in the above list revers to the R#7.1-style mechanism of showing a bulb pop-up. The last option prevents any visual queues that a bulb item is available (save for the indicator itself), and only shows the menu when you explicitly open it with Alt+Enter.

Please note that this feature is available only for Visual Studio 2010 and later.

Decompiler Improvements

We’ve already talked a bit about decompilation (both in ReSharper and dotPeek), but this deserves a mention: we now know how to correctly decompile

  • async methods and await expressions, including async lambdas.

  • Expression trees — the decompiler will now help you when exporting Linq to SQL or Entity Framework code in query expressions. This means in ReSharper 7 you could only decompile an expression into this:

    whereas with ReSharper 8 you can decompile it into this:

  • Field-like events, taking into account the lock-free nature of C# 4’s add/remove accessors.

Fix in Scope

In-place fixes are great, but what’s even better is when you can apply that fix in a given scope. Take those pesky unused references, for example – now you can get rid of them not only in a file, but also on a project/solution level. All with a single quick-fix:

Now quite a few fixes can be applied to a larger scope than just the code under the cursor — including making a field read-only or removing a redundant cast.

Default Alignment Setting Adjustments

One common complaint about ReSharper’s default settings was that certain constructs we indented, shall we say, aggressively. The two particular cases of note are anonymous lambdas

And another case is indentation when a function call including parameters gets too big and is indented similar to

These and similar cases will now be treated more gently by ReSharper’s default settings.

Code Inspection Performance Improvements

Last, but certainly not least, after another round of performance improvements we’ve managed to once again speed up ReSharper’s code analysis. Specifically, the Find Code Issues command enjoys an over 2× performance improvement.

Now, you know what to do – grab the EAP and check out those features today!

This entry was posted in ReSharper Tips&Tricks and tagged , , . Bookmark the permalink.

16 Responses to ReSharper 8 EAP, Build 3: What’s New!

  1. arjuns says:

    Typescript ?..

  2. Dmitri Nesteruk says:

    @arjuns work on TypeScript support is ongoing.

  3. Joe White says:

    “Less indenting” and “fix in scope” both sound awesome (though “fix in scope” has significantly more awesome).

    Any ETA on the test-runner bugfixes for parameterized NUnit tests? I’d love to try the EAP again, but I need to get work done too.

  4. says:

    When the first blog post about the EAP was published, a few people said that ReSharper 8 looked underwhelming. At the time, I agreed.

    But seeing all these new features has made me change my mind.

  5. Florian says:

    Might be willing to give it a whirl if the download link in the confluence page is updated?

  6. @Florian
    Is it not? You should be looking for build dated April 4.

  7. No wonder: we’ve warned that we’d reveal features in batches )

    @Joe You’re referring to RSRP-343003, right? We’re looking to make fixes public before end of April.

  8. Joe White says:

    @Jura, awesome, thanks for the update. Yes, RSRP-343003 is the one keeping me from upgrading to R#8 (due to bugs I can’t work around).

    It’d be great if you also got a chance to fix RSRP-337720 (existing test-runner bugs in 7.1). I can usually work around that one by running my tests a second time, but when they’re integration tests that take a few minutes to run, and I’m trying to write a few dozen new tests and run them as I go, I’d really much rather have the test runner work the first time.


  9. Hannes K says:

    More important than any small feature additions would be a decoupling of Resharper, meaning splitting into modules that I can deactivate to save resources. Working with Resharper on legacy systems within my workenvironment is painfull.. starting it takes 10 seconds, and in my opinion a lot of people would pay gladly if they would get async R# loading (nonblocking), and/or performance improvements.
    Make VS snappy again, please. There is no reason to block my UI, it’s 2013, we got async now bult into C#. Which also works in .NET4 with the async tagetting pack. _Please_ make performance a topmost priority, people care about that more than you might think (make a uservoice site, whatever, but collect feedback outside the small circle of cracks using your EAP).

  10. Joe White says:

    @HannesK: You’re complaining about 10 seconds to start ReSharper on old hardware? It must be nice to work on such a tiny project!

    Put that in perspective. We have about 100 projects in our solution, ~1.5 million lines of code. It takes several minutes for ReSharper to start up (especially if I wait for solution-wide analysis to finish re-analyzing — VS is responsive during that time, but the benefits are worth waiting for). That’s with good CPUs and 8GB of RAM.

    But so what? I only start up Visual Studio a couple of times a week. I’d welcome your 10-second startup time, but I’d much rather have the R# team spending their time giving us good performance on “use many times a day” features, rather than on “once or twice a week” features.

  11. Hannes K says:

    Hey buddy, aren’t you a cool one..
    We have the latest and greatest hardware and SSDs.. 8HB, 8 core, SSDs, no, not old hardware. 10 seconds (that’s a normal solution, it’s up to 20 for our biggest one) is just unneccessary, esp. because that is a rather small solution, maybe 5 projects. We split our codebase up into many (~50) smaller solutions, because VS2010 couldn’t handle it anymore. If you have 100 projects _loaded_, even in VS2012, I don’t know what you’re doing, partial loading them via VS extension, or whatever, but just because your situation is worse doesn’t better mine. But thanks for boasting. Our project has 2mio lines of code btw, but we can’t load them all, due to Memory issues, esp. with Resharper.

    But you’re right, compared to the other problems, R# loading time is probably a minor issue.
    I’d rather have the R# team spend there time giving us good performance on “use many times a day” features like.. typing! Or opening more projects because Resharper can finally lazy-async-load stuff into memory instead of consuming 600MB upfront. It took them already quite some refactoring to cope with the new enforced async project loading in VS2012, they should spend more time there, and follow that route. Use the new ImmutableCollections like the VS guys do, etc.

    @R# team: again, this time maybe without a “hey but I’m way cooler than you” response inbetween, please consider improving your resource consumption, it’s increasingly problematic, esp. with increased featureset. Or, if that is not problematic, please blog a perf-related R# post, I’m sure there are others like me who would like to see some perf explenations and what was and is done in that direction.

  12. Joe White says:

    I see, I misunderstood. When you said “Working with Resharper on legacy systems”, for some reason I read “legacy systems” as “old hardware” (“system” = “PC”), and I was wondering why 10-second startup on an old PC would be a problem. Now it’s clear you meant “legacy code base”, which makes much more sense. Sorry for the misunderstanding.

  13. Paul says:

    Does anyone have an xslt they’re using to hook this in to CI? I want to run this through Jenkins but I don’t want to write my own xslt if there’s already one out there. That would be a really good thing to include with R# 8 once it goes gold.

  14. @Hannes
    Which ReSharper version are you using?
    Also, have you previously provided performance snapshots to the ReSharper team for investigation? If you haven’t, we’d be happy to investigate. Please let us know if you’d be eager to provide performance snapshots. Thanks

  15. @Paul Possibly someone from the community has a ready to use XSLT but nothing from JetBrains so far.

  16. Chris Marisic says:

    About time for the fix in scope, i’m pretty sure I requested this feature back in 4 or 5.

Leave a Reply

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

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>