Dotnet logo

The .NET Tools Blog

Essential productivity kit for .NET developers


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

UPDATE: Rider EAP build 18 re-introduced CoreCLR debugging on Windows. Implementations for Linux and macOS will make their return later, stay tuned.

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

Comments below can no longer be edited.

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

  1. MichaelD! says:

    May 7, 2015

    Yes… disable support for JavaScript and TypeScript. That is most excellent advice. Die JavaScript. The world can do better without you. 😉

  2. Greg Sohl says:

    May 7, 2015

    One of your support team told me you have a web installer avail. Would be good to include details on it here.

  3. Steve says:

    May 7, 2015

    I’d be interested in a blog post on how you built your unified installer – is it entirely custom or is it using an off-the-shelf library or toolset? We’ve had no end of issues with installer suites.

  4. Grady says:

    May 8, 2015

    What Steve said. Whether you made the installer in house or used a product, it looks fantastic and modern. Share your installer knowledge oh oracles!

  5. Dew Drop – May 8, 2015 (#2010) | Morning Dew says:

    May 8, 2015

    […] ReSharper Unified Installer. Why? (Alexey Totin) […]

  6. Carlos R.J. says:

    May 13, 2015

    Good news…I am going to test all you tools.

    I have one question, what tool do you use to create your installer?

  7. Christoph Linke says:

    May 14, 2015

    Can I upgrade my personal ReSharper 9.1 license to one with which I can use also dotMemory, dotTrace and dotCover?

  8. Tony says:

    June 4, 2015

    The “No annoying license notifications” is too quiet!
    There was some problem with my JB account, so that Resharper suddenly decided I wasn’t licensed for anything. I didn’t get any notifications: all the resharper functionality just up and disappeared, and most of the settings went away. There was no indication that this was licensing related.
    I even uninstalled and reinstalled and ReSharper, before I thought to check my license information and saw that my JB account said I had no licenses.

  9. Some one says:

    June 12, 2015

    This unified installer sounds good in theory but sucks chunks by not playing well with previous version of your product.

  10. Miika Hänninen says:

    July 24, 2015

    Can the installer (either the downloaded one or the one that’s included in the installed product for plugin management) be called externally to install plugins to resharper?
    I’ve been thinking of creating a chocolatey package to bootstrap a development system quickly, including resharper, plugins and settings, so this feature would be great for that.

    • Alexey Totin says:

      July 24, 2015

      The current answer is no, this is not possible.

      • Miika Hänninen says:

        August 2, 2015

        Ok, thanks for the response.
        Have you had any plans for such a feature?

  11. Carsten Sponsel says:

    July 27, 2015

    The annoying detail of the new shared platform is with handling floating licenses. E.g. dotCover now will occupy a license on Visual Studio startup – that was different with Resharper 7 and dotCover 2.7, here Floating Licenses were occupied after actual using the product.
    Everyone who uses dotCover is a developer (at least in our company) and uses Visual Studio. So at the moment Floating licenses are almost senseless.
    That’s a great drawback of the in other respects excellent JetBrains tools.

    • Daria Dovzhikova says:

      July 28, 2015

      Hello Carsten,

      Apologies for the inconvenience, this is a known issue with the latest versions of dotCover. The only thing I can offer at this point is to watch this issue for future updates:

      • Carsten Sponsel says:

        July 29, 2015

        Hello Daria,

        i know that issue – it was created after my bug report 😉
        But until now I do not have much hope that it will be fixed soon 🙁
        Maybe via this page I find some supporters for a bugfix…


  12. Ross says:

    January 14, 2016

    I have to say, I’m really not all that pleased with the unified web installer. I mean, it installs things, so that’s good. However, I have no idea how long I have to sit and wait for the installer because all the progress bars are indefinite. Nothing tells you how large the download is, how fast it’s going, how long it’s going to take, etc.

  13. Ross says:

    January 14, 2016

    I’m now less pleased with it. I had to run the installer a second time, which required me to wait for it download everything again. Does this not do any caching and version checking?

  14. sriaknth says:

    October 14, 2016

    How can we install ReSharper 9.0 in AllUser Mode ? IF yes can some one help in installing it in all users mode silently using silent switches


  15. Hung Nguyen says:

    February 15, 2017

    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.

  16. Joseph Woodward says:

    February 16, 2017

    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.

    • Joseph Woodward says:

      February 16, 2017

      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:

        February 16, 2017

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

        • Joseph Woodward says:

          February 17, 2017

          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:

            February 19, 2017

            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 🙂

  17. A Rafay says:

    February 16, 2017

    New update doesnt recognize Unity3D Project Code anymore on macOS. 🙁

    • Matt Ellis says:

      February 16, 2017

      Sorry about that. The Unity plugin needs an update. I’ll publish a new version as soon as I can, likely tomorrow.

      • Matt N says:

        February 20, 2017

        Hi Matt,

        Any updates on how this is going? Thanks for all your hard work

        • Maarten Balliauw says:

          February 20, 2017

          Latest plugin should be good again. You can update it under Settings | Plugins.

    • Wob says:

      February 16, 2017

      Noooooo! I just noticed this 🙁 Looks like back to Xamarin for now.

      • Ivan Shakhov says:

        February 16, 2017

        You can disable Unity plugin for today, Rider will be operable and check the updated plugin tomorrow.

  18. Carel Lotz says:

    February 16, 2017

    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.

    • Hadi Hariri says:

      February 16, 2017

      We’ll do our best to make sure it’s sooner rather than later.

    • KenBonny says:

      February 16, 2017

      In the meantime, you could use VS Code to do the debugging.

  19. Rakkattakka says:

    February 16, 2017

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

    • Maarten Balliauw says:

      February 16, 2017

      EAP17 should be available in toolbox now.

  20. Kirill Rakhman says:

    February 16, 2017

    Updating from withing Toolbox doesn’t seem to work.

    • Pete says:

      February 16, 2017

      For me as well 🙁

      • Maarten Balliauw says:

        February 16, 2017

        EAP17 should be available in toolbox now.

  21. Pete says:

    February 16, 2017

    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.

    • Petr says:

      February 20, 2017

      In your opinion, which languages/ecosystems are more interesting and powerful in the long run?

      • Ben says:

        February 21, 2017

        Very few …

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

        * Mobile Android/iOs
        * Windows / Linux / MacOS … Application ( .net, xamarin, Mongo )
        * Windows / Linux / MacOS … Servers / Backed / Console ( .net Core )

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

        • Christopher Romero says:

          March 16, 2017

          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?

  22. Kai M. Wadsack says:

    February 16, 2017

    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:

      February 16, 2017

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

      • Kai M. Wadsack says:

        February 16, 2017

        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:

        February 18, 2017

        Can you please PM me?

        • Maarten Balliauw says:

          February 19, 2017

          You’ve got mail 🙂

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

    February 16, 2017

    […] .NET Core applications that target CoreCLR {$excerpt:n} submitted by /u/rubyantix [link] [comments] Source: […]

  24. Rider EAP 17 steht zum Testen bereit – says:

    February 16, 2017

    […] Informationen zu allen Neuerungen in Rider EAP 17 finden sich im zugehörigen Blogpost. Über die Projektwebsite kann der aktuelle Build heruntergeladen […]

  25. Dew Drop - February 16, 2017 (#2423) - Morning Dew says:

    February 16, 2017

    […] Rider EAP 17: NuGet, unit testing, good and bad news on debugging (Maarten Balliauw) […]

  26. Rider EAP 17 steht zum Testen bereit - says:

    February 16, 2017

    […] Informationen zu allen Neuerungen in Rider EAP 17 finden sich im zugehörigen Blogpost. Über die Projektwebsite kann der aktuelle Build heruntergeladen […]

  27. Marcel Bradea says:

    February 16, 2017

    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 (, CEO of MS) and the .NET team right away ( – 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 ( 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:

      February 16, 2017

      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:

      February 16, 2017

      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:

      February 16, 2017

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

    • Jack Holster says:

      February 20, 2017

      This is kind of a dick move.

      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.

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

    February 16, 2017

    […] 情報源: Rider EAP 17: NuGet, unit testing, good and bad news on debugging – .NET Tools Blog […]

  29. Deepak Khopade says:

    February 16, 2017

    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.

    • Jack Holster says:

      February 20, 2017

      Without that very vested business interest you decry, MS wouldn’t be able to allocate the time and resources on .NET Core, so you wouldn’t have the open source stuff in the first place at all.

  30. Steven says:

    February 16, 2017

    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.

  31. Damian Turczynski says:

    February 16, 2017

    Is it possible to download EAP 15 somewhere now?

    • Damian Turczynski says:

      February 16, 2017

      I meant EAP 16…

      • Maarten Balliauw says:

        February 16, 2017

        The previous EAP is time-locked I’m afraid. Are you seeing any issues with the current EAP (other than the obvious)?

        • Damian Turczynski says:

          February 17, 2017

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

          • Maarten Balliauw says:

            February 17, 2017

            We hear you, we definitely hear you. Appreciate the response and support – we’ll definitely find a solution to bring back debugging support for .NET Core!

            If you happen to be on Windows, you can always target the full framework to enable debugging for now, and then switch back to CoreCLR when appropriate.

  32. Ben says:

    February 16, 2017

    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.

    • Hadi Hariri says:

      February 16, 2017

      Thank you for the support Ben. We’ll definitely find a solution to bring back debugging support for .NET Core

  33. Dmitriy says:

    February 16, 2017

    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:

      February 16, 2017

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

    • Colin Rosen says:

      March 19, 2017

      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.

  34. Dylan Beattie says:

    February 16, 2017

    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.

    • Hadi Hariri says:

      February 20, 2017

      Dylan, we’re currently discussing the possible options. We’ll keep you all updated.

      • Dylan Beattie says:

        February 22, 2017

        Thanks, Hadi. Look forward to hearing something soon 🙂

  35. Jens says:

    February 16, 2017

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

  36. Urs Meili says:

    February 16, 2017

    a propos rider debugging: when will it finally be possible to debug multiple projects at once (see e.g. this is a must-have for a lot of applications which consists of a client and a server.

    • Maarten Balliauw says:

      February 16, 2017

      We’ll be looking into that, make sure to watch the issue on YouTrack for updates.

  37. Yury says:

    February 17, 2017

    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.

    • Maarten Balliauw says:

      February 17, 2017

      Thanks! We’re looking into these interfaces. To be continued 🙂

    • Marcel Bradea says:

      February 18, 2017

      Thanks so much guys (whole community) for getting on this

      Yuri, way to point the team in the right direction

  38. Michael Lojkovic says:

    February 17, 2017

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

    • Maarten Balliauw says:

      February 17, 2017

      Can you try if disabling the Unity plugin fixes it?

      • Michael Lojkovic says:

        February 17, 2017

        Yeah, that does it.

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

    February 18, 2017

    […] 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 … Continue reading → – Read full story at Hacker News […]

  40. Mads Skipper says:

    February 21, 2017

    Is it possible to do the “Start external program: somedir” in rider yet?

    Also when in the “Debug” I cant seem to change project (Isnt that the startup project?)

    • Maarten Balliauw says:

      February 21, 2017

      Not yet (as part of run configuration). Under settings, Tools | External Tools you can add a tool to show in the menu and optionally assign a keyboard shortcut to it.

  41. Russ Aram says:

    February 23, 2017

    The elephant in the room is Visual Studio Code. Add Resharper support and forget Rider.

  42. Ramprit Sahani says:

    March 1, 2017

    How to enable C# 6 feature in rider 18.

    • Maarten Balliauw says:

      March 1, 2017

      C#6 should just work. For C#7, type some C#7 syntax (like a simple local function) and use the quick fix to enable support.

      • Ramprit Sahani says:

        March 1, 2017

        No When i use string interpolation like
        so this is not working.
        I throw exception

        • Maarten Balliauw says:

          March 1, 2017

          Are you seeing an Exception in Rider? Or when running the application? What is the Exception message?

          • Ramprit Sahani says:

            March 1, 2017

            In rider.
            rider is not support c# 6.
            plz enable

            • Maarten Balliauw says:

              March 1, 2017

              Can you send me a screenshot at maarten.balliauw at jetbrains dot com?

  43. Why so Anti-Microsoft Lately? – I C# People... says:

    March 8, 2017

    […] mean to pick on Seb here, but they’re the examples that sprung to mind). Not to mention the debugging library fiasco […]

  44. George Cook says:

    March 13, 2017

    Anyone else got the annoying bug where the font size for both IDE and editor fonts get’s set to something massive (like 60) every time you restart rider. Already tired of it.. anyone got a quick fix?

  45. Alternatywa dla Visual Studio? Rider od JetBrains – Paweł Skaruz o dotnecie i bezpieczeństwie says:

    April 23, 2017

    […] to brak możliwości debugowania aplikacji w .NET Core. Nie jest to winą Rider’a, a postanowień licencyjnych. Wykorzystanie pakietu umożliwiającego debugowanie aplikacji .NET Core możliwe jest tylko w […]

  46. Rider C# IDE Now Has .NET Core Debugging Again | Lifehacker Australia says:

    June 18, 2017

    […] February, the Rider team was forced to disable .NET Core debugging as the particular NuGet package they were using had different licensing to the rest of .NET […]

  47. Mcat says:

    October 18, 2017

    How to user nuget console package manager. I can’t find this menu.
    For example , i want to migrate to in nuget console package manger , but now ,i can’t do it .

    • Maarten Balliauw says:

      October 18, 2017

      The NuGet tool window is the only way to manage packages, other than editing .csproj or packages.config. No console is available right now.

Discover more