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.)

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.

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.

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.

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 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.

NuGet

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.

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:

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.

Build

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).

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.

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!

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.

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

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.

After trying out D, Nim, Rust, Swift, Crystal, Haxe, Go and a whole bunch of others for months on end. Only a few stand out.

* Apples Swift had a lot of potential. But it seems to be constantly in the whole 2/3/4 API breaking everything, missing features etc. While .net Core is also not exactly feature filled, Swift had almost two years extra to produce results. They are still trying to get Swift to work on Windows for Version 4, in 2017 … 3 years after release. Great language bad eco system with almost pure iOS/Apple product focus.

Too early released. Think of version 1/2 as Alpha 1, Alpha 2 .. Version 3 is more or less RC material. And people will say that Swift will work on Linux. Sure … with half the standard library not working. People need to use IBM there BlueSocket implementation just to use sockets! Let alone trying to write a file to a disk on Linux and you keep seeing Mac examples.

Eco system wise, if your not on Mac, your choices are very limited. Jetbrain probably has the best non-Mac solution with the Swift plugin for CLion.

* Rust is a more cross platform and very well developed language but lets just say its not easy. Be ready to fill your code up with ‘.unwrap’ everywhere, trying to design around the manual memory design etc. It has potential but its just way to user unfriendly. Interesting if you come from C/C++ but its learning curve is also its downfall.

They are supposed to make it more user friendly in 2017 but from seeing the current releases, no real work is actually being done on that part ( just more features ).

The Rust eco system, is frankly not too bad. Compared to a lot of those other projects, there eco system is still in active development. The Jetbrain cLion plugin is very actively developed.

* Go has a lot of potential but will be limited to mostly server / console tasks for the future. Its Googles pet project for there internal server management and its clear on there focus ( GC, GC, GC … ), that it will be console/server material forever. But its cross platform support is great.

Eco system is also good because of more and more support. Jetbrain is bringing out a new editor pure for Go ( Gogland ), so they also see a future there.

The rest on that list is mostly limited to specific ecospaces or is seeing a slow dead.

The only language that i found beyond C++, that allows most then just one platform or one specific ecosystem is C#:

Trust me, i am not a fanboy. Send the last 4 or 5 months trying out just about every new language for ages. I never considered C# because who wants to run .net on Linux Servers. Its heavy, slow, you need different platform implentations ( .net, xamarin, Mongo ) just for console / Server work. Crazy one will think. Until .net Core.

Very few of those new languages that are in development or active, allow for mobile or visual application development. Because that is a whole different game, so there focus is mostly system/console/server. And they rely on 3th party implementing wrappers around libraries like GTK. But a lot of those projects get abandoned after a while.

Now my logic is. Why learn several languages for front end applications and back end, when i can target multi platforms with one same language.

I am not saying that .net Core is feature complete. Nothing more fun as finding out errors like:

error CS0246: The type or namespace name ‘HttpListener’ could not be found

That is for standard 2, what is .net Core 2.0 for Q3/2017. But its hell of a lot more feature complete then Swift. *lol*

And regarding those “more interesting and powerful things” happening in other languages. Please name some and then i can tell you most of those features you will never use.

From my point of view, C# is the way to more forward. Its not sexy. It has a bit of a stale reputation. But one can not deny that very few languages beyond Jave/C/C++, that allow so may ecosystems to be targeted, with different front or backend applications.

There are a lot of language projects and some are very interesting but a lot simply reinvent the wheel. I lost count on the amount of time spend learning those languages and trying them out. In the end, they all do the the same with maybe some twists like macros, manual memory management etc but they all end up as LLVM/Clang compiled executable.

The reality is, very few grow outside there base ecosystem because of lack of support, missing libraries, people giving up, people not maintaining libraries, communities being hostile to change / stepping outside there base etc …

So please take my comments with some salt as a C# newbie but i am frankly fed up with all the promises of a great future on those new languages. 😉

Hey Ben –
thanks for the thoughts. I can guess what you’d say but you didn’t mention the Javascript stack. I’m very wary there myself but it does provide a server option as well as client options. Thoughts?

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.

Hi!
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.

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).

Community:
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

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.

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.

Why start what is essentially a spamming campaign without first learning more about the situation? it could be completely unintentional or it could be something that they have no control over. Or as it turned out in this case, this is a proprietary component that Microsoft built but the underlying interface itself is open source, so JetBrains could build their own debugging capabilities around it as they choose.

There are proper channels to seek feedback for cases like this. .NET Core is developed in the open, so you can open an issue in any one of their repositories. Or you can make a post in the .NET Foundation forums. But spamming a bunch of blog posts is not the right way to do things.

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.

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.

TL;DR: It’s just the obvious.
Maarten we are heavily investing in .net core and rewriting whole product to .net core. I love Rider, but without debugging it’ll be much harder (impossible?) to convince people to use it :(. It’s a shame MS is still using monopolistic strategy :(.

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. 😉

Hi Dmitriy.
I don’t know if you’re still experiencing this problem, but I managed to fix it. For some reason I had to enable the case sensitive check for the regexes.

What I did was:
– Press shift+shift.
– Type ‘TODO’
– Go down in the list in under ‘Settings’ where it says ‘Editor -> TODO’
– Enable ‘Case sensitive’ (I enabled it for all of them) and save
– Afterwards I disabled it and it still works

I have no idea how or why this works. I don’t know if it’ll work for you for that matter, as I have no way of testing it. Nevertheless, I hope this helps you or perhaps someone else with the same problem.

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.

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! 😉

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.