[neonsunset]

They use their own in-house implementation. There's an OSS alternative from Samsung https://github.com/Samsung/netcoredbg but I haven't heard of anyone using it.

In general, the debugger is not intentionally made unavailable but rather the "properietary" one is just the original Visual Studio debugger extracted into a standalone package adapted to cross-platform.

Other than that, CoreCLR exposes rich debugger API, and debugger implementations just integrate with it, there are no "private bits" that would make this task insurmountable, there was just not much need to do so so far, and some Linux folks (as evidenced by skimming through other .NET submissions here) tend to have irrational and unsubstantiated hatred towards .NET which hinders otherwise positive community efforts.

[jen20]

> debugger is not intentionally made unavailable

> rather the "properietary" one

The fact that it is proprietary intentionally makes it unavailable for use outside of Visual Studio and Xamarin Studio - this actually caused debugging to be unavailable in Rider for a while a few years ago before they built their own.

[neonsunset]

This is a strange statement. That said debugger also comes with base C# extension, which is free and debugger aside, MIT, in VS Code on all platforms. Xamarin Studio and VS for Mac are deprecated.

Given the confidence of your reply, one would assume you'd know this? Unless it's the exact problem I outlined previously, in which case please consider sharing grievances about something you do use actively instead, rather than what you think are .NET's issues.

[jen20]

A timeline:

- The MS Debugger was use in Rider - thus was perfectly functional from a technical perspective.

- It was later discovered that the license was proprietary, allowed only for MS products. VS Code is one of those. The extension may legally not be used with VS Codium or other such telemetry-neutering builds.

- The debugger was removed, and debugging of Core CLR apps was unavailable while JetBrains found an alternative (which did not take very long).

As I alluded to, the fact that this worked, and was just prevented by licensing makes it a construct solely of proprietary software licensing. It was well documented at the time:

- https://blog.jetbrains.com/dotnet/2017/02/15/rider-eap-17-nu...

- https://blog.jetbrains.com/dotnet/2017/02/23/rider-eap-18-co... news-about-coreclr-on-windows

As for daily driving: I was the first person outside of JetBrains to get hands on Rider. The fact that I don't write C# _daily_ in 2024 does not mean I have no first-hand knowledge of what was happening in 2016-2018, or indeed today.

[neonsunset]

These events predate .NET Core 3.1, which what I consider the baseline where "the new" .NET gotten good enough for businesses to migrate to. Before that there was a lot of uncertainty, breaking changes and culture shock, the echo of which is still felt to this day. Nonetheless, this holds little influence on the state of affairs in the last few versions, certainly since .NET 5, which, if I understand your first reply correctly, is the criticism in question.

Would you like to put it against Go for lacking package manager, Java for being stuck on version 8 or Rust for not having stable language server? /s

Or, to phrase it differently, "this is an issue" - "it was an issue in 2018" - "no, you don't get it, it's a valid criticism because nothing can ever be improved". You see how flawed this argument is?

I'm so tired of these low effort replies here that it's just sad, in technical conversations in other contexts I'd equally defend another language when someone blatantly misconstrues the facts. I don't have a horse in this race at this point, it's simply annoying to try to converse productively when the quality of replies is this low. I should probably spend time elsewhere.

[Nullabillity]

The difference is that it's still an issue in 2024.

[neonsunset]

It's not. Base C# extension for VS Code is free and MIT[0], the closed component, that is a debugger, is free as well. There is an open-source alternative too, and what effectively all debugger implementations do is integrate with debugger API provided by .NET itself, which any new tool can hook into. At the same time, Rider uses its own homegrown debugger, that works even better and has nice time-travel capability.

[0]: https://github.com/dotnet/vscode-csharp (this is _not_ DevKit, which is optional, the actual language support like Roslyn language server is part of the base extension, and you really don't need DevKit which has "extra VS-style accommodations" most of which can be done with different extensions, if that's what you want)

[jen20]

A great example of moving the goalpost post-hoc.