Rider EAP 18: CoreCLR debugging is back (on Windows)

Good news everyone! A fresh Rider Early Access Program (EAP) build is available for download!

Rider splash screen

Rider EAP 18 brings back CoreCLR debugging on Windows (Linux and Mac OS X will come later), the Invalid volume separator char solution load error has been fixed, there’s a UI to add COM references and display them in the Solution Explorer, and assorted bug fixes. In other words: things you want! Check out the list of fixes in this build for full details.

Debugging: good news (about CoreCLR on Windows)

Last week, we shared the bad news that we had to temporarily disable debugging CoreCLR applications in Rider. CoreCLR debugging on Windows is back! (Linux and Mac OS X will come later)

It’s now possible again to launch and debug a CoreCLR application and step through code, inspect variables, add watches, and all goodness that can be expected from a debugger.

CoreCLR debugging is back in Rider (Windows)

We can also attach to a running CoreCLR process from the Run | Attach to Local Process… menu.

Attach to CoreCLR process

Support for COM references

Rider now supports adding COM references to a project. In the Solution Explorer, we can use the Add reference… context menu on a project to search and add references – both system libraries as well as COM libraries. Of course, references can also be added from disk.

Add reference to COM libraries

Once the reference is added, it will be displayed in the Solution Explorer together with other references.

COM references in Solution Explorer

Bugfixes

We fixed a number of issues since the previous EAP. Most noteworthy:

  • Fixed solution load errors with Invalid volume separator char exception.
  • Fixed invalid dangling foldings in editors that haven’t been opened for a long time.

If you were seeing any of these issues on your solutions, try out the latest Rider EAP build and let us know how it goes.

Download

Go ahead and download the latest Rider EAP build!  As always, your feedback and comments are highly appreciated!

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

21 Responses to Rider EAP 18: CoreCLR debugging is back (on Windows)

  1. Smad says:

    Seems like you forgot to update version number for eap 18, autoupdater of eap 17 doesn’t suggest new version (difference only in build number).

  2. Pingback: CoreCLR debugging returns in JetBrains Rider (on Windows; Linux, macOS to be added later) | Ace Infoway

  3. Pingback: Rider EAP 18: CoreCLR debugging is back (on Windows)  | OPC Diary

  4. Anthony says:

    Update not populating in the Toolbox app? Says I’m up-to-date with EAP 17?

  5. Vladimir Kozlov (ai_enabled) says:

    Could you elaborate a little more on the CoreCLR debugging feature? Has Microsoft updated the license model?

  6. Anatoly Popov says:

    Do you have any plans about debugging of .net core apps in Docker containers?

  7. Pingback: Dew Drop - February 24, 2017 (#2429) - Morning Dew

  8. Pingback: Swift 4 Release-Prozess & Machine Learning gegen Hatespeech

  9. Pingback: Dew Drop – February 24, 2017 (#2429) (by Alvin A.) - ugurak.net

  10. pete says:

    Congratulations on bringing debugging (on Windows) back so fast!
    Rider is pretty awesome already!
    Keep up the good work!

  11. Pingback: Rider IDE恢复了对.NET Core调试的支持 – ITYet-

  12. Fantastic work guys.
    Do you mind elaborating on the state of things for Mac?

    ie: Architecturally is this a very large effort or is a port/cross-platform solution of the Windows approach/fix feasible, and it’s just a matter of time?

    Just give us an expectation to set… before we go out and buy our devs a bunch of emergency Windows machines.

    Kind thanks!

    • Kirill Skrygan says:

      Hi Marcel!
      We are working hard to fix .Net Core debugging outside of Windows as soon as possible. We are expecting this to be done during March this year.

      Technically, this effort is not so huge architecturally, we should just fix COM-Interop on Mono.

  13. benjiro says:

    Silly question but is it possible to allow non 1.0.0-preview2-1-003177 versions of dotnet Core to be used.

    Currently the option dialog allows the changing of the dotnet.exe path but when a user has 2.0.0-alpha installed, Rider will complain about not finding 1.0.0 and not work properly.

    For instance setting a extra text field in the options menu to not only allow selected the dotnet.exe path but also the version? This makes testing code against never versions more easy.

Leave a Reply

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