ReSharper Ultimate 2016.2 Release Candidate

Ladies and gentlemen, you can now download ReSharper Ultimate 2016.2 Release Candidate!

All new features and improvements that we have revealed and blogged about in recent months are now in pre-final state.

This includes things as exciting as textual search via Go to Text, structural navigation with Tab, and warnings in solution-wide analysis, as well as more mundane fixes, of which there are plenty.

If you still have pressing issues with 2016.2 RC or if something that we assume fixed doesn’t actually solve your issues (btw, everyone who has been unhappy about Move to Folder behavior with TFS, we’re waiting for you to confirm a fix), this is probably your last chance to let us know via comments here, or better yet, via issues in respective product trackers: ReSharper, ReSharper C++, dotTrace, dotMemory, dotPeek or dotCover.

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

24 Responses to ReSharper Ultimate 2016.2 Release Candidate

  1. Blake Niemyjski says:

    Would love to have .net core test runner support.

    • Jura Gorohovsky says:

      We’d love to, as well, but we weren’t able to make it work in a stable manner in time for the release. Expect this to be available in 2016.3 EAP (probably in September).

  2. Richard Haber says:

    How long does it take before extensions become available again for a new release

  3. says:

    Just a note on the download page’s UX: the top right “Download” button doesn’t download the RC. It caught my eye before the “Download RC” button did.

  4. Pingback: ReSharper Ultimate 2016.2 – das ist neu -

  5. Pingback: Dew Drop - August 12, 2016 (#2308) - Morning Dew

  6. Ian Johnson says:

    Between not being able to run unit test (a big reason to buy R#) and major problems with Razor syntax in .net core (who needs intellisense for nested properties …). It feels like this release doesn’t fully support .netcore. Why not hold the release till these major features are there and actually work?

    • Jura Gorohovsky says:

      This release doesn’t indeed support .NET Core in full because running .NET Core tests is not supported so far. This is unfortunate, and we’ll provide an update supporting .NET Core tests as soon as we can.

      We’re not holding back the release because there’s a substantial number of changes that are complete and there’s no reason to holding them back.

      As to problems with Razor syntax in .NET Core, we’d love to have a more specific feedback. Is there probably a bug report with details on this?

      • Ian Johnson says:


        There is RSRP-459597 and I personally mentioned it in RSRP-458975 a month ago and the response from jetbrains was that this was a known issue and as of friday declined to be fixed for 2016.2.

        I’m usually a big JetBrains supporter but 2016.2 support for ASP.Net core is lacking and leaves a developer like myself in the situation where I have to decide between ReSharper intellisense (which works better for C# but broken for TagHelpers) or Regular intellisense (not as nice for C# but works 100% with CSHTML).

        • Jura Gorohovsky says:


          As far as I can see, recent comments in RSRP-458975 have been narrowed down to RSRP-459079, which is now set to fixed (and I’m hoping it really is.)

          AFAIK subproperties are not supported so far as their usage is not found in public ASP.NET Core samples, and supporting them requires certain additional effort. AFAIK there’s a workaround whereby you can use <input asp-for="@Model.SubModel.SubProperty1" /> instead of <input asp-for="SubModel.SubProperty1" />

          • Ian Johnson says:


            When I turn off ReSharper intellisense Visual Studio intellisense presents me a list of sub properties and does not require any additional effort. It 100% out of the box works the way you think it should (though R# flags complains it can’t resolve the sub property).

            Technically I guess putting an @Model infront of everything would work (not tried it but taking your word for it) but that seems exceptionally awkward and wrong. I shouldn’t have to work around R# limitiations.

            Model binding and intellisense for sub properties and lists has worked in MVC for years. Is it your assertion that this functionality is no longer supported in MVC Core?

            • Slava Trenogin says:

              Hi Ian!

              Model binding and intellisense for sub properties and lists has worked in MVC for years. Is it your assertion that this functionality is no longer supported in MVC Core?

              How is it related to new functionality of ASP.NET Core, like tag helpers?
              BTW, even VS tooling is still in beta, preview2 to be exactly.
              And there are no examples, tutorial or just OSS project using nested model properties in tag helpers.
              Can you, point me to one, please?


              • Ian Johnson says:


                To your question of how is this related, under the covers TagHelpers use the same IHtmlGenerator implementation as the HtmlHelper do. As HtmlHelper syntax has always supported nested properties, I would expect TagHelper to support nested properties, which is a good assumption as the code and intellisense works.

                I can create can create a quick project showing nested properties working with VS intellisense if that helps. I can throw it up on github to make it easier to access.

                As for examples or tutorials I’m not sure I’ve seen one from MS but the documentation is a little light. I’m working off the assumption that because VS supports nested properties through intellisense and when executed the html produced is correct that it’s supported.

                So as not to clutter up this blog feel free to contact me over email directly or in one of the youtrack tickets that are open to track this.


          • Ian Johnson says:

            For your edification, I posted a question on the MVC github repository asking about documentation on sub property support in TagHelper and this was the reply:

            “There’s no specific documentation. As for sub-properties, they should just work. Is there something you’re seeing that makes think otherwise?”

          • eyoung100 says:

            That work around didn’t work when I tried it. See: [Shopping Cart]( for a practical example. Notice that ShoppingCart.aspx contains BoundFields, with data values containing nested naming, i.e. Product.ProductName. In order for R# not to complain, you must convert the BoundField items to an ItemTemplate, which requires more typing:

  7. Vita Tauer says:

    I tested RC’s command line tools, and they do not support .net core project. Is this feature ever planned in 2016.2?

    • Jura Gorohovsky says:

      Vita, we’re planning to update CLT to support .NET Core but this isn’t expected earlier than in 2016.3.

  8. Pingback: Szumma #052 – 2016 32. hét | d/fuel

  9. Thomas Stocker says:

    I have one remaining Issue with Resharpers overload resolution, Somehow Resharper thinks DateTime and DateTimeOffset are the same Type if used from a portable Library.

    I hope that gets fixed before a release.

    • Jura Gorohovsky says:

      Thanks for reporting this, Thomas. However looks like this doesn’t make it to the release; let’s see if this can be addressed in a subsequent bug fix update.

      • Thomas Stocker says:

        Thanks for looking into it.

        P.S.: As a side note Resharper has a lot of BugFixes that makes it still worthwhile to update, especially Performance Bugfixes.

Leave a Reply to Jura Gorohovsky Cancel reply

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