Rider EAP 23: .NET Core debugger is back, Code Cleanup, and more

There’s a new Rider EAP build available for download, and it’s full of changes, large and small, including Code Cleanup, new project and solution settings, VB.NET project templates, F# unit testing, an updated console, per-framework Solution Wide Analysis results, as well as hundreds of bug fixes.

However, one thing clearly stands out:

.NET Core debugger is back on Mac and Linux

Back in February, we were forced to temporarily disable .NET Core debugging due to a licensing issue (for a recap, here’s what happened). Restoring the functionality on Windows was fairly straightforward (it only took us one week); Mac and Linux, not so much.

Finally, following a few months of reading, writing and debugging code, scratching heads, testing and fixing, we’re ready to roll it out: you can debug .NET Core on OS X and Linux again.

.NET Core debugging on Mac and Linux is back

What else to say? Thanks for bearing with us.

In related news, Rider can now use MSBuild shipped with .NET Core SDK. In practical terms, what it means is that you no longer need Visual Studio on Windows or Mono on Mac/Linux to open and build .NET Core projects with Rider.

Rider has received more debugger improvements in this build, such as the following:

  • .NET Core debugger’s Console view is working again on Windows, Mac, and Linux, including input/output redirection.
  • There’s now a Results view in Variables for enumerables where items are enumerated and shown as a list.
  • Backing fields are no longer shown as duplicate items in the Variables tab.
  • 30+ more debugger fixes, including an annoying issue resolving breakpoints to symbol documents (RIDER-6330).

Code Cleanup

Rider thrives on making ReSharper features available on the IntelliJ platform. However, some ReSharper features (especially if they involve custom UI) require substantial porting effort, and Code Cleanup is certainly one of these. However, in this EAP, we’re finally introducing the initial implementation of Rider’s own Code Cleanup:
Code Cleanup

Depending on the selected cleanup profile and your preferences, applying Code Cleanup on a file or a wider scope will simply reformat your code, or additionally apply code style rules and remove code redundancies: the list of actions that Code Cleanup supports is really long.

As of this EAP, Rider’s Code Cleanup doesn’t let you customize profiles (this is work in progress) but if your solution contains saved ReSharper settings, Rider will respect them and expose cleanup profiles that are defined in them.

F# unit testing and more improvements

Rider’s F# plugin has received a few notable improvements that make use of the underlying ReSharper infrastructure.

You can now run and debug NUnit or xUnit unit tests. Tests and test fixtures are discovered, highlighted in the editor, and are available to run, debug or add to sessions via the Alt+Enter menu. If necessary, you can run tests written in C#, VB.NET and F# in the same test session.
Rider discovers and runs F# unit tests

Rider’s Extend Selection and Shrink Selection are now available in F# code, letting you successively select expanding logical blocks of code, and vice versa.

Finally, Rider learns to take F# code into account when it looks up your solution for to-do items and displays them in the TODO view:
To-do Explorer supports F#

Target frameworks in Solution-Wide Analysis

Rider’s Solution-Wide Analysis has been extended to understand target frameworks. If your solution contains code targeting multiple frameworks (such as .NET Core and .NET Framework, or multiple versions of .NET Framework), the Errors in Solution tool window will let you filter errors by framework, or, if you choose to show errors that affect all frameworks, you can see which target frameworks are affected by each particular error.
Target frameworks in the Errors in Solution view

You don’t always want to display target frameworks under all error items, and you can toggle this presentation with the Show Frameworks in Tree toggle button in the toolbar.

Projects and settings

We have reworked the Project Properties window to make it accommodate more project configuration items and have a saner UI:
Project Properties window

On a related note, there’s now a Solution Properties window that lists and lets you manage debug/release build configurations available on solution level and and per-project:
Solution Properties window

Rider allows creating quite an array of various .NET project types, but prior to this build, the list didn’t include any VB.NET project templates. This is now fixed as class library and console application templates are available for VB.NET:
VB.NET project templates

We are putting considerable effort into clearly notifying you about any required toolsets, SDKs and other components that Rider needs to operate correctly. In this EAP, we have introduced a set of diagnostic notifications that Rider shows when it fails to load projects in your solutions:
Notifications on project load failure

Web.config and MSBuild files

This EAP improves support for web.config (and whatever.config) files: we have brought a set of Rider’s XML features to .config files, such as typing assistance, tag and attribute completion, navigation to namespaces, code formatting, and XML structure view in the editor:
IntelliSense in web.config

On a related note, a built-in XML schema for MSBuild files (.csproj, .targets etc.) improves XML validation and enables smart code completion.

Reworked console

The console that Rider shows in the Run tool window has been reworked, which hopefully removes a series of annoying bugs such as weird characters on executing Console.ReadLine(), broken Console.ReadKey(), and incorrect cursor behavior.
New Rider console

More improvements

  • Search Everywhere now understands combo searches that are separated by dot (in addition to whitespace separators):
    Search Everywhere supports dot delimiters
  • The Refactor submenu in context menus now properly displays ReSharper refactorings where applicable. This also makes refactorings available in the Structure view:
    Refactorings in Structure view
  • Various fixes in code highlighting: no more empty tooltips; less literal highlighter blinking; better highlighting across color schemes; no more duplicating Colors & Fonts settings pages for web languages.
  • We finally stopped showing IDE theme samples written in Java when you launch Rider for the first time 🙂

The obligatory closing paragraph

Get the latest Rider EAP build and try it out. Please reach out to us if you face any critical issues.

Comments below can no longer be edited.

19 Responses to Rider EAP 23: .NET Core debugger is back, Code Cleanup, and more

  1. Avatar

    Joseph Woodward says:

    June 16, 2017

    Awesome work! Great to see the return of the debugger for us folks on Mac and Linux!

    Is anyone else experiencing slow solution loading times? Even with a solution with three projects, Rider still seems to take a while.

    Keep up the great work!

    • Avatar

      Jura Gorohovsky says:

      June 22, 2017

      Thanks, Joseph! AFAIK you’re in touch with the dev team regarding slow solution load: hoping they can solve the problem soon.

    • Avatar

      Sirwan says:

      June 24, 2017

      my laptop (MacBook Pro Retina, 15-inch, Mid 2015) fans also runs at full speed after opening a solution with three projects.

  2. Avatar

    A new dev says:

    June 16, 2017

    Damn this is a huge release, thanks a lot! 😀

    • Avatar

      Jura Gorohovsky says:

      June 22, 2017

      Thank you!

  3. Avatar

    A H says:

    June 16, 2017

    Trailing whitespace in new line should be tagged “annoying” (IDEA-91809) 🙁

    • Avatar

      Jura Gorohovsky says:

      June 22, 2017

      Looks like there’s a workaround available.

  4. Avatar

    Vladimir Nabokov says:

    June 17, 2017

    Any chance for Xamarin support on Linux?

    • Avatar

      Cedric says:

      June 19, 2017

      I think the to do is at xamarin itself, actually their compiler and tooling is windows only

      • Avatar

        0xFireball says:

        June 23, 2017

        It isn’t Windows-only; there is IDE support on macOS and Windows, and the command line tools support macOS and even Linux. But there’s no official IDE support and it’s not that easy to get working manually, and I still couldn’t get the debugger to attach.

    • Avatar

      Jura Gorohovsky says:

      June 22, 2017

      You might want to watch RIDER-5747 although this doesn’t seem to be on our immediate schedule.

  5. Avatar

    Roman Petrenko says:

    June 17, 2017

    Does not look like debugger works. It throws exeption like:
    Exception in debugger process: Exception in debug session RegisterForRuntimeStartup async result. Value does not fall within the expected range. The error code is COR_E_ARGUMENT, or E_INVALIDARG, or 0x80070057.

    • Avatar

      Carl says:

      June 21, 2017

      I get the same issue, latest macOS 10.12.5 on iMac (27-inch, Mid 2011), any reason why this would happen?

      • Avatar

        Jura Gorohovsky says:

        June 22, 2017

        Looks like getting the latest stable .NET Core SDK should solve this problem (source).

  6. Avatar

    Jens says:

    June 19, 2017

    What a cool release, thanks a lot for giving DotNet Core on Linux that much Love!
    All the essentials are working out of the box again since the bumpy move from project.json to msbuild. Cool work!

    A question: What are the requirements for Dotnet Core F# projects on Linux? I got mono-complete and msbuild installed on Ubuntu 16.04 but within Rider I got:
    Could not load file or assembly ‘Microsoft.Build.Utilities.v12.0, Version=, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a’ or one of its dependencies.
    whereas gacutil tells me that it is installed.

    And finally a small request: xunit tests do work perfectly in Rider for dotnet core/Linux, though would be cool if nunit support for dotnet core/msbuild like described here would return.

    • Avatar

      Eugene Auduchinok says:

      June 22, 2017

      Do you have a separate fsharp package installed as well?

      • Avatar

        Jens says:

        June 23, 2017

        Thanks for your reply. What do you mean by separate f# package?
        The f# plugin in rider is enabled and my sample project ( build and runs just fine on the commandline.
        Regards, Jens

        • Avatar

          Jens says:

          June 23, 2017

          I think I got what you meant, but even after installing the fsharp package (apt-get install fsharp/dnf install fsharp) from the mono repositories the message stays the same.
          Note: This is .Net Core in my case, eventually I had missed somewhere that F# support is only there for the full .net framework, though not sure what the exact support in Rider is…

  7. Avatar

    Oleg says:

    January 21, 2018

    Is it possible to enable ‘Show compiler-generated code’ like in dotPeek for Windows?
    I’d like to use it in Rider for Mac.


Discover more