[ubercow]

It's very frustrating having all of these tools only support Windows.

Despite all the wonderful work Microsoft has done with CoreCLR, the "IDE" debugger is still only available under a license that only permits use with Visual Studio and VSCode [1] and mdbg is still nowhere to be found for CoreCLR [2].

1: https://github.com/dotnet/core/issues/505 2: https://github.com/dotnet/coreclr/issues/1145

From what I've gathered, the best you have right now for doing command line debugging is the "SOS" plugin for lldb, which seems to require building the lldb plugin and sometimes even lldb (!!) yourself [3][4].

3: https://github.com/dotnet/coreclr/blob/master/Documentation/...

4: http://blogs.microsoft.co.il/sasha/2017/02/26/analyzing-a-ne...

Not very fun if you're not using Windows.

[jahewson]

The “IDE” debugging library fuss was mistaken. CoreCLR supports the same COM ICorDebug API as mainstream .NET but Microsoft have their own private C# bindings library for using it with VS/VSCode. Anybody can generate their own C# bindings, JetBrains already did.

I say this as someone who was using ICorDebug 13 years ago.

[megaman22]

Why would they support anything but Windows? Unless it's a bleeding edge tool, it predates .NET Core, and .net Core is still immature.

[systems]

how does jetbrains rider ide provide debugging then

[xadoc]

Jetbrains was using a package provided by Microsoft and blogged that they would soon have to disable debugging of CoreCLR

Read “The Bad News” https://blog.jetbrains.com/dotnet/2017/02/15/rider-eap-17-nu...

Also the licensing issue https://github.com/dotnet/core/issues/505

Then a week later with the licensing issue still in place Jetbrains implemented their own debugger, on the comments it reads "This is our own debugger implementation." https://blog.jetbrains.com/dotnet/2017/02/23/rider-eap-18-co...