Rider EAP 17: NuGet, unit testing, good and bad news on debugging

Ah, the scent of fresh software in the morning. We just published a fresh Rider Early Access Preview (EAP) version, go grab it! (Unless you’re about to debug .NET Core: if you are, read on first.)

Rider splash screen

What’s in this build? Significant performance improvements were made, shared projects are now supported, code inspection severity can be configured, settings for our unit test runner can be edited, various updates to the NuGet tool window UI, and more. Check out the list of fixes in this build if you feel like digging into details.

Before we proceed with good news about this build, we have to share some bad news: as of this build, we’re temporarily disabling CoreCLR debugging in Rider. Here’s why:

Debugging: bad news (about CoreCLR)

In the near future, Rider will not allow debugging .NET Core applications that target CoreCLR. This is due to a licensing issue with a package that we’ve been using*. We were using this functionality considering it part of .NET Core which is Open Source, but it turned out that this specific package has a different licensing model. It explicitly only allows usage from Visual Studio, VS Code or Xamarin Studio.

CLR debugger usage rights limited to Microsoft IDE's only

Given this is the only package that is available that exposes the debugging API for .NET Core, we are evaluating our options as to how to resolve the matter and will be looking to restore CoreCLR debugging functionality in coming months. In the meantime, if you want to debug .NET Core applications on Windows, you can target the full .NET runtime instead of CoreCLR.

* This might lead to a 404 as Microsoft have confirmed they mistakenly published the package on NuGet.org and will be removing it shortly.

Bad news over

Only good news ahead.

Debugging: good news

In the previous EAP of Rider, we added displaying of variable values in the editor, right next to the code, and added navigation to code from the variables tab.

Rider debugger displays variable value in editor

Conditional breakpoints were already there, so we can tell the debugger to only break execution when a variable has a certain value, e.g. person.Name == "Maarten". In this new EAP, we added hit count filters. What if we suspect a bug only occurs in the 1.000 iteration of a loop? Step over a thousand times? Hit count filters help in telling the debugger to only break after the breakpoint was hit a number of times. We can specify the filter using Ctrl+Alt+B on a breakpoint.

Debugger hit count filter

Do explore this dialog some more, as there is some great debugging functionality in there (such as only enabling a breakpoint if another breakpoint was hit).

Code completion

When code completion suggests a method, Rider now displays a summary info popup. It displays the method’s summary and parameter information. If there are multiple overloads, we can switch between them using the left and right arrow keys.

Code completion summary popup

Code completion is now available when working with colors in C#, XAML and CSS. Rider suggests available colors which we can use in our code. Not only that: the editor will also underline the selected color so that when reading code, our brain can parse things more easily using visual cues.

Code completion for colors


We made quite some changes to the NuGet experience in Rider. Various bugs were fixed, project.json and UWP support was improved. A very visible change is in the user interface: we redesigned the NuGet tool window.

Instead of three panels, there are now only two. On the left-hand side, installed packages and search results are shown. The list also highlights the package source that was used to retrieve the package. On the right-hand side, we display package metadata as well as the projects the package is installed in, with buttons to upgrade, downgrade, install or uninstall the package.

NuGet tool window UI updates

Inspection severity

Code inspections help us adhere to code style settings and general development best practices. We can apply a quick-fix to let Rider help us update the code for us. Severity of these inspections can be configured from the settings, or simply from the editor using Alt+Enter:

Code style quick-fix and severity

Unit testing

The Rider unit test runner has been there for a while, and we now added a settings page for it. Under Build, Execution, Deployment | Unit Testing, we can configure options like the platform architecture or .NET Framework version to use. Shadow-copy and AppDomain options can be specified as well.

As a bonus, unit testing settings (and various other settings, too), can be stored in ReSharper settings layers and shared with team members working on the same solution, whether in Rider or ReSharper.

Unit testing settings


The Build tool window can show us the raw build log (as text), or a summary of warnings and errors in a tree view. From the tree, we can Jump to Source (F4) and navigate to the next/previous item (Ctrl+Alt+Up/Down).

Navigate through build results and jump to source

In the Solution Explorer context menu (or under the Build menu), we can build the entire solution or individual projects with MSBuild diagnostics enabled. This will set verbosity to diagnostic, providing us with more details of what is happening during build.

Performance improvements

Significant performance improvements were made in the new Rider EAP. Code completion is much snappier, and there is virtually no latency when typing. We also improved NuGet client performance.

On Linux and Mac OS X, we fixed slow Solution Analysis, which played mostly in ASP.NET projects. Turned out to be an interesting bug! Fixing it did result in better performance and resolved backend crashes and exceptions related to file paths.


We hope that even though we have to suspend CoreCLR debugging for now, you’ll want to test-drive the latest Rider EAP build!  Your feedback and comments are appreciated!

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

62 Responses to Rider EAP 17: NuGet, unit testing, good and bad news on debugging

  1. Hung Nguyen says:

    Please improve the look and feel of the IDE, make it more coloful and elegant:
    – the C# file icon look so bad
    – the toobar icons looks boring

    You guys have made the IntelliJ look and feel very good, so please for Rider.

  2. It’s a real shame to hear about the difficulty you’re having with the debugger. I would have thought this would be something that Microsoft would have licensed or provided in some way, I’m shocked to hear that it’s considered a key competitive advantage to Microsoft products.

    • Just been reading more about debugging implementations in .NET Core and jumped to conclusions about what this meant; I’d retract the second part of my above comment if I could =) Either way, looking forward to seeing the debugger return in the next release hopefully, keep up the awesome work!

      • Toby J says:

        Could you elaborate? I’m also reading this to mean that it’s not possible to debug CoreCLR without reverse-engineering, which is extremely disappointing given all the noise Microsoft is making about .NET Core being “100% open source and cross-platform.”

        • My understanding (and someone please correct me if I’m wrong) is the Visual Studio NuGet package Rider was originally using was Microsoft’s own implementation of the .NET Core’s open-source ICorDebug interface.

          Microsoft have spent a great deal of time and energy building advanced debugging features around this open interface and wish to protect the value of Visual Studio (which is completely understandable).

          There’s nothing to stop JetBrains building their own implementation of the ICorDebug interface as it’s open-sourced and available to anyone. In fact, there are currently a few open-source implementations of the interface, just none as fully featured and tested as Microsoft’s.

          Bottom line seems to be, JetBrains are not blocked, they just can’t use the Visual Studio implementation of the ICorDebug interface.

          • Toby J says:

            Thanks, that does make sense, and makes it seem like the above sentence “this is the only package that is available that exposes the debugging API for .NET Core” is a bit misleading. I’m sure JetBrains will come up with a great solution though :)

  3. A Rafay says:

    New update doesnt recognize Unity3D Project Code anymore on macOS. :(

  4. Carel Lotz says:

    Sad to hear that I need to start up the Windows VM again. Hoping you can resolve the CoreCLR debugging soon. “In the coming months” sounds ominous though.

  5. Rakkattakka says:

    Could you please specify when the update will be available through JetBrains Toolbox?

  6. Kirill Rakhman says:

    Updating from withing Toolbox doesn’t seem to work.

  7. Pete says:

    Well, I personally am not worried about Core CLR debugging because I don’t have plans to look at .NET Core for at least another 6-12 months cause it still is a big mess IMHO, the ecosystem is far from being mature and ready for any serious development, the bare runtime is not enough, I need working and solid tools that support .NET Core and before that happens MS has to stabilize the thing, i.e. NCrunch, a critical tool for my workflow, still does not support .NET Core and this is strictly MS’s fault.
    So given the expected time frame I foresee for .NET Core to become ready for serious development I’d expect JetBrains to come up with a working solution that in the long run I can only expect to become better than MS’s own debugging (this is pretty obvious to me when looking back at the accomplishments and attention to details from both companies).
    PS. Not to mention that In the long run I’m looking to quit .NET completely cause there are more interesting and powerful things happening in other languages/ecosystems.

  8. Kai M. Wadsack says:

    If it only were for .NET Core projects that can’t be debugged, I could perhaps live with it.
    But as things currently are, debugging doesn’t work for me at all.

    This is a console application self hosting a ASP.NET WebAPI (full framework) project using OWIN. I’m on macOS Sierra using Mono 4.8.0 (mandatory if you want to use VS Preview for Mac).
    Alternatively I tried this with xsp4 hosting the WebAPI.

    Result is the same:

    Before the first public EAP 14 release debugging worked fine.
    Starting with EAP 14 you could debug once. If you stopped debugging, fixed your bugs and then restarted debugging, Rider would fail to attach to the debugger. Only way to get debugging to work again was to restart the the Rider IDE.

    Now with EAP 17, the “Can not attach to debugger” bug seems to be fixed.

    Breakpoints are reached and respected, but you cannot “Step over” or “Step into” or resume from a breakpoint.
    Pressing F10 or using the option from the menu doesn’t seem to do anything.

    Setting the breakpoint at other places in your code, very often leaves you with the “step …” options greyed out.

    Rider is already superior to XS and VS when it comes editing and refactoring your code.
    Just like the ReSharper options on Windows are superior to the native options in VS on Windows offers.

    But as long as debugging isn’t working, you can only use it as a code editor. For debugging you have to fall back to VS or XS.

    • Hadi Hariri says:

      This should be working. Is there anything you could send us to reproduce the problem?

      • Kai M. Wadsack says:

        I just tried to create a demo project to give you something to reproduce the problems I’ve got here. To my big surprise, debugging worked flawlessly in the demo project.

        I then tried again in the project I’m currently working at, and had to find out that some of the API’s method can be debugged while others can’t. Currently it seems to be fifty/fifty. But I haven’t found a scheme yet.

        I’ll try to find out tomorrow, what is causing it to fail.

      • Kai Michael Wadsack says:

        Can you please PM me?

  9. Pingback: Rider will not allow debugging .NET Core applications that target CoreCLR | Ace Infoway

  10. Pingback: Rider EAP 17 steht zum Testen bereit – entwickler.de

  11. Pingback: Dew Drop - February 16, 2017 (#2423) - Morning Dew

  12. Pingback: Rider EAP 17 steht zum Testen bereit - zend-framework.net

  13. Guys, the debugger is a critical deal-breaker for any Mac .NET development (probably the primary reason/benefit for Rider’s existence, over say Resharper).

    Can everyone tweet to out Satya (https://twitter.com/satyanadella, CEO of MS) and the .NET team right away (https://twitter.com/dotnet) – and let them know to fix this – with an executive order, if that’s what it takes. Please also add a comment on the .NET blog (any and all blog posts are fine). Let’s swarm them and show that this is totally unacceptable (https://blogs.msdn.microsoft.com/dotnet/). We need to rally as a community against decisions like these and show that we will not stand by watching it happen. PLEASE TWEET AND DROP COMMENTS on blog posts RIGHT NOW (it’s the fastest thing we can do to ring the alarm).

    JetBrains Team:
    Have you reached out to Microsoft about this issue yet? What’s their stance? It’s most likely either an oversight or some historic licence that is out of line with their strategy of open-sourcing .NET / giving developers options on different platforms.

    If we receive word that this is UN-intentional, please start a petition immediately and spread to the JetBrains .NET community. This is beyond unacceptable and we don’t have months to wait. Some of us that started spinning up critical components on Linux/MacOS .NET Core cannot go without debugging for a week, let alone months. As for using the MS Mac tools, VSCode/Xamarin has NOTHING on you guys. And Rider being announces was literally the TRIGGER for us putting our eggs in the .NET Core basket :)

    • David Fallah says:

      I completely agree, this is absolutely unacceptable on Microsoft’s part and a huge disappointment for me, as someone looking forward to this release so I can continue development of a .NET Core project on Mac.

      I don’t have Twitter but I’ll be trying to reach out to Microsoft about this in other ways.

    • Greg Lincoln says:

      I doubt the licensing is an oversight/legacy given that it mentions Visual Studio Code specifically, and that is a very new product.

      Microsoft has been very much multi-faced with their stance toward open source and community involved development. Just look at the mess with DNX/rc2 and project.json.

      I think there are advocates at the company who strongly believe in doing the right thing, but they have to fight the nightmarish old guard who are terrified of change and making open source .net too good. If .net core was too good, everyone would stop buying expensive Windows Server and Visual Studio licenses.

    • Mike-EEE says:

      I thought JB was on some MSFT .NET council or some such? Seems like you could leverage that relationship.

  14. Pingback: Rider EAP 17: NuGet, unit testing, good and bad news on debugging – .NET Tools Blog | OPC Diary

  15. Deepak Khopade says:

    such a bad start of the day :(
    On one side MS is trying to promote to open source community and they seriously did with .NET Core but now taking debugging out due to some vested business interest, how to call this as an open source framework. Shame.

  16. Steven says:

    I am disappointed as well to hear about the lack of CoreCLR debugging, what is MS thinking? This is a definite showstopper for Mac development of .NET Core applications outside of VS for Mac (should that early preview ever become stable).

    My organization had us jump on .NET Core early and we have a lot of developers using Macs (previously a lot of java and node.js work) and are currently using VS in Parallels. The org wants to ditch Parallels so we were excited with the EAP of Rider having used a lot of JetBrains IDEs in the past, but this pretty much takes Rider out as a possibility for us unless we want to deal with multiple IDEs (VS Code for debugging, Rider for development), which is not ideal.

    I look forward to JB finding a way to resolve this.

  17. Damian Turczynski says:

    Is it possible to download EAP 15 somewhere now?

  18. Ben says:

    I am curious what the plan is and if there’s anything we as a community can do to help. For instance if there is another open source debugging solution maybe we can start contributing.

  19. Dmitriy says:

    Oh, debuggers, debuggers… And I’m sitting here with TODO list showing nothing and ‘Errors in Solution’ showing some nonsense :(

    I join Damian’s question – can we get EAP16 back for an additional month? I really, really don’t like to go to VS for Mac.

    • Sascha says:

      No, it’s just not possible due to the license. I think there is currently no interest by MS regarding this issue, because VS2017 is coming soon and they do not need concurring products at launch right now. 😉

  20. Pingback: JetBrains removes CoreCLR debugger from cross-platform C# IDE due to licensing issues - How to Code .NET

  21. So I’m trying to get a bit more perspective on what’s happened here, since the whole clrdbg thing has exploded a bit. I’m assuming Rider’s going to be a closed-source commercial product when it reaches RTM, which would impose certain legal restrictions on what components it can use. I’m also under the impression that this isn’t a *change* to the licensing terms of Microsoft.VisualStudio.clrdbg; it’s that Rider’s use of that package has always been in violation of those terms but that it’s only just come to light. If anybody can confirm or deny these assumptions, please do.

    I’m interested in the qualifying statement: “Given this is the only package that is available that exposes the debugging API for .NET Core”

    What’s the status of ICorDebug in the latest coreclr? When you say ‘the debugging API for .NET Core’, do you mean clrdbg is the only package that exposes debug information via a managed (i.e. .NET Core) API, or that it’s actually impossible to debug coreclr code without using the clrdbg package?

    As somebody who’s trying to promote .NET Core and battling a constant barrage of anti-Microsoft sentiment, it’s really discouraging to see this kind of friction between MS/.NET Core and Rider, but I’d like to understand more about what’s actually going on, and what specific events and changes have led to today’s announcement.

  22. Jens says:

    Could you please take a look at the font-rendering on Linux? While the rendering was nearly perfect on EAP 16 it seems now somehow broken. Subpixel AA isn’t working anymore and the editor window seems somehow scaled, the font is way to small with default settings. I’m seeing this behavior on recent Fedora and Ubuntu LTS, both with system JDK or Oracle JDK.

    Regarding Linux, I’m using Dotnet Core as .Net environment exclusively on my Linux machines, I have no mono installed and I would like to keep it like this. Resharper works perfectly (well, with the exception of the debugger now :( ) but I got constant IDE errors about mono not being detected. Since everything works I wonder why this message constantly pops up?

    Finally, I’m really looking forward to the final release, you are doing cool work here and I’m keen to throw my money at you once it’s ready! 😉

  23. Urs Meili says:

    a propos rider debugging: when will it finally be possible to debug multiple projects at once (see e.g. https://youtrack.jetbrains.com/issue/RIDER-3977)? this is a must-have for a lot of applications which consists of a client and a server.

  24. Yury says:

    Asked a friend who used to work on .NET debugger at MS, he said JetBrains should try using this and related interfaces.

    According to him, this is an official debugging interface for CLR and it’s available at all platforms.

    MDbg nuget (a console-mode debugger) is built on top of this API and its source code can be used as an illustration.

    The friend says, he can give contacts of a MS developer who can help with the task. PM, if interested.

  25. Michael Lojkovic says:

    Did code completion stop working for anyone else, on Linux?

  26. Pingback: Rider EAP 17: NuGet, unit testing, good and bad news on debugging - .NET Tools Blog

Leave a Reply

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