ReSharper 6.1: The Finish Line

Jura Gorohovsky

A couple of days ago, we have started to release ReSharper 6.1 nightly builds in production mode, with build 30 being the first one of the new breed.

What sets production builds apart from regular development builds is that exceptions are suppressed, meaning no more wild life in the right corner of the status bar, and performance is slightly better due to lower count of checks, asserts and whatnot. Basically, production mode builds is what you get when we deliver betas, release candidates, and final release builds.

What it all means for you is that if you’re generally reluctant to trying nightly builds due to the annoyance of exception reporting and general mistrust, this might be the right moment for you to test-drive ReSharper 6.1 before we release it — even more so considering that we’re not planning any beta releases prior to 6.1 RTM.

Having said that, please grab a fresh nightly build and try it out. Here’s the list of issues that separate us from releasing 6.1. If you think there are any more show-stopper level issues, please be quick to ping us here in comments or by creating a bug report. Thank you!

Comments below can no longer be edited.

19 Responses to ReSharper 6.1: The Finish Line

  1. David Zidar says:

    December 14, 2011

    I’d love to see this bug fixed

  2. Joe White says:

    December 14, 2011

    Hmm, so that’s how you deal with things like the “an item with this key already exists in the dictionary”-after-every-keystroke errors I’ve been reporting for the last couple of weeks? You just stop reporting them in production builds? Interesting.

    I was wondering why you were going to “production ready” with that one still outstanding. I guess this explains why. Everything still seems to work fine even while it’s throwing these exceptions left and right, so suppressing the errors is probably not totally unreasonable… although I do have to wonder which features are quietly failing to work because of this exception, without me knowing anything about it.

  3. Jimmy Headdon says:

    December 14, 2011

    I REALLY need to see the memory consumption issues with R# 6.1 EAP fixed before the release candidate appears, even with the today’s nightly build R# is competely unusable under certain circumstances, especially whilst using edit-and-continue in Visual Studio 2010, even editing a simple jQuery whilst debugging, or opening a largeish file cause R# to throw a wobbly and crash VS.

    I have raised multiple bugs surrounding this and up until the exceptions were supressed I filed lots of repeat issues, and without an upgrade to dotTrace to stop it crashing and deleting my snapshot (even without VS integration selected on install) I cannot submit anything to help!

    These really need to be addressed before a release candidate is considered.

  4. Valeriu Caraulean says:

    December 14, 2011

    There is an issue with VS2010 hanging after update:

    Any hints/workarounds to get VS back?

  5. Ed says:

    December 14, 2011

    I doubt this one is that hard to fix, it’s marked as critical, and it’d be nice if it worked as it should!

  6. Jura Gorohovsky says:

    December 14, 2011

    @David A workaround is provided in the comments to the issue as far as I can see.

    @Joe Here’s the root exception, fixed yesterday I think.
    Also, it’s always been like this: in nightly builds, exceptions are displayed and are ready to be reported, in production builds they are suppressed (which is of course preceded by eliminating critical exceptions)

  7. Jura Gorohovsky says:

    December 14, 2011

    @Necroman, @Ed
    I’m afraid I don’t have any encouraging news for you regarding the issues you specified.

    This is one of the show-stopper bugs that we’re looking to resolve before release.

  8. Jura Gorohovsky says:

    December 14, 2011

    As far as I know all your requests where you provided snapshots have been processed. In total, 30 requests submitted by you have been fixed for 6.1 this far.
    Since you’re still having trouble with memory consumption, the most efficient thing you can do right now is provide us with memory snapshots. Capturing memory snapshots doesn’t require using dotTrace as it’s done using another tool. Please see this document for memory profiling guidelines.
    If you’re able to upload the snapshots tomorrow (on Thursday), there’s a chance we might be able to make changes and push them into 6.1. Thanks!

  9. Joe White says:

    December 15, 2011

    @Jura: that root exception has a “Fixed in build” of Does that mean it won’t actually be fixed in the 6.1 release, and we’ll be stuck with background analysis occasionally seizing up (now with no warning) until VS is restarted?

  10. Jura Gorohovsky says:

    December 15, 2011

    @Joe No that means that this particular change was initially committed to trunk before being merged to the 6.1 branch

  11. Mark Monster says:

    December 16, 2011

    Are you guys at Jetbrains planning to support WinRT?

  12. Jura Gorohovsky says:

    December 16, 2011

    Absolutely. Not in version 6 though.

  13. orangy says:

    December 16, 2011

    @Mark, of course we have plans to support WinRT. The problem is there is no build suitable for integration work. Developer Preview has some critical API missing (or non-functional), so we are waiting for something to work with.

  14. Phil says:

    December 20, 2011

    RSRP-284665 is a show stopper for us. Any chance this can be fixed?
    RSRP-279821 is also a problem.

  15. Jura Gorohovsky says:

    December 20, 2011

    Sorry but we don’t currently support custom build actions at all, meaning that RSRP-284665 can’t be implemented right now.

  16. Justin says:

    December 20, 2011

    RSRP-286341 and RSRP-286345 both show fixed in 6.5 but the issues persist in the latest 6.1 nightly build. Will the fixes for those bugs get merged into the 6.1 branch before 6.1 is released?

  17. Jura Gorohovsky says:

    December 20, 2011

    @Justin We’re past the 6.1 inclusion deadline. The two fixes will apparently be available in the next ReSharper update after 6.1.

  18. Justin says:

    December 20, 2011

    Hmm, the Fixes link for nightly build 30 lists those bugs as fixed in that build.


Subscribe to .NET Tools updates