free-vscode-csharp VS vscode-cpptools

The debugger is proprietary but still works cross-platform. I don't know how Jetbrains does C# debugging in Rider exactly, but that shows that you don't have to use VS (Code) to do C# development if you don't want to.

Thanks to Samsung of all companies, there's an open source C# debugger on GitHub (https://github.com/Samsung/netcoredbg). That seems to be the basis of the open source C# extension's debugging capabilities: https://open-vsx.org/extension/muhammad-sammy/csharp

The VSCodium C# community wants Microsoft to open source their debugger instead of having to maintain an open source version themselves, but that doesn't mean you need to use Microsoft's open source version. If anything, this forceful separation makes it so that there never will be only one implementation (like there is for languages like Rust which have always been open and therefore only have one way of doing things).

If you don't like XAML, you can use https://github.com/AvaloniaUI/Avalonia.Markup.Declarative to write declarative SwiftUI-like code. You can also use F# if that's your cup of tea: https://github.com/fsprojects/Avalonia.FuncUI.

If you prefer GTK, there are rich GObject bindings that are a successor to GTK#: https://gircore.github.io/

Here are samples that demonstrate basic GTK4 usage scenarios: https://github.com/gircore/gir.core/tree/main/src/Samples/Gt...

All this should require less than 10 minutes including setup and such.

Lastly, I want to make a disclaimer that you do not need C# Dev Kit extension for VS Code, only the base C# one, which is what gives you language server, debugger, etc. If you are using VSCodium which cannot use closed-source vsdbg component that the base extension uses, you can replace it with https://github.com/muhammadsammy/free-vscode-csharp which uses open-source debugger from Samsung instead. It can be rough around the edges but works well enough in standard scenarios. Just don't use Debugger.WriteLine over Console. :D

C# extension works well and uses Roslyn Language Server that is part[0] of the Roslyn (C# compiler) - this is what the base C# extension[1] uses. Both of these are licensed under MIT.

The only closed-source component is 'vsdbg' which is Visual Studio's debugger shipped as a component that the extension uses. It, however, can be replaced with Samsung's 'NetCoreDbg' by using the extension fork[2].

[0]: https://github.com/dotnet/roslyn/tree/main/src/LanguageServe...

[1]: https://github.com/dotnet/vscode-csharp

[2]: https://github.com/muhammadsammy/free-vscode-csharp

> I spent way too long trying to get netcoredbg to work, and couldn't get it to do much of anything. Maybe it's less of a shitshow now? Given that your original reply wasn't "yeah nobody uses the MS debugger anyway", I somehow doubt it.

This got me curious. Turns out there exists an actively maintained fork of the official C# extension that comes with NetCoreDbg instead: https://github.com/muhammadsammy/free-vscode-csharp

I was able to successfully debug simple async code with it after installing the vsix, disabling the official one and restarting VS Code without changing any other settings.

So, for the trivial case it works. Submitted issues do indicate further compatibility problems like not supporting "Debug.Write" methods (just use a logger or Console.Write I guess?) or instability when bridging this extension to something that isn't VS Code.

Still, someone even managed to get it to work with Cursor: https://github.com/dgokcin/dotnet-cursor-debugging-with-brea...

> For comparison, Scala and Rust have cultures that emphasize printf-friendliness, and I rarely have to reach for a debugger at all. The difference it makes for my sanity is immense (as someone who wasted years on the shitshow that is .NET).

This is the first time I hear someone tout print-based debugging as an advantage. The approach F# takes with printfn "%A" might be more to your taste. Otherwise, DebuggerView and DebuggerDisplay are there for a reason, and I don't understand the case for not using a debugger. And when you do insert WriteLines, or logger writes, there are many tools to make the output pretty. Making a simple extension method that will do indented JsonSerializer.Serialize is already a start. Records also come with default ToString implementation.

I only tried F# for few days, but it was a pleasant experience on both macos and linux.

dotnet CLI should take care of build process, it can even generate self-sufficient executable (that bundle parts of .NET in them). The infamous required XML boilerplate has also been cut down to near-zero.

My biggest gripe is that Microsoft's debugger is closed-source and proprietary (though free for users of official VSCode builds). There is open-source netcoredbg by Samsung, so you can use VSCod[e,ium] with https://open-vsx.org/extension/muhammad-sammy/csharp , but YMMV.

When looking into C# tools though, my understanding is that the main debugging tool is under a proprietary MS license, although maybe I'm misunderstanding that. My question is, is there a FOSS debugger or tool kit for C# development? I did find this on the marketplace but am not sure if this is what I'm looking for. I know this is a bit of a niche case but was hoping to clarify. I'm not committed to VSCodium and am open to other text editors/IDEs, although would prefer to stick with it if possible.

My understanding is that I can install VSCodium and that they have many of the most popular extensions available. They even seem to have an alternative for the C# debugger. I could also use VSCodium and manually install the Microsoft extensions from the distributed VSX files.

and there is a VSCode extension that uses this instead of the MS debugger

https://open-vsx.org/extension/muhammad-sammy/csharp

intelliSenseMode needs to be set appropriately for your platform. This link has a list of platforms where you can set it.

Its close in spirit to DRM. They want to ensure that if you are using their projects, it must be under their terms.

Many of their VS Code extensions[0] have license terms which /prohibit/ them from being used in editors that are not Microsoft's VS Code editor, and Microsoft can issue cease-and-desist for violation of this or use of their extension marketplace in alternative editors.

Microsoft has a pattern they follow where they publish repositories on GitHub to proclaim they are open source, while actually distributing proprietary binary blobs in them that are fundamental core parts of functionality to the codebase[2][3][4]

[0] https://github.com/microsoft/vscode-cpptools/issues/6388#iss...

[1] https://github.com/microsoft/vscode-cpptools/issues/5784

[2] https://github.com/microsoft/win32metadata/issues/766

[3] https://devlog.hexops.com/2024/building-the-directx-shader-c...

[4] https://github.com/microsoft/Azure-Kinect-Sensor-SDK/issues/...

The C/C++ extension is open source with MIT license but the shipped extension binary contains MS proprietary binaries that is not as open [1]. I am not sure what will be the difference between using MS official build and compiling the source (there will be some for sure).

[1] https://github.com/microsoft/vscode-cpptools/blob/main/LICEN...

Now if only MS would fix VSCode[0] :'(. Come on, the feature if more than half a decade old and this point.

0: https://github.com/microsoft/vscode-cpptools/issues/6302

🔗 Link to GitHub Issue: Add Similar Function - https://github.com/microsoft/vscode-cpptools/issues/11477

According to this: https://github.com/microsoft/vscode-cpptools/issues/3423 it seems to be at least somewhat possible to reuse natvis files from Visual Studio, but I have not tested that. Never really had the need to look at any non-vector container in the debugger.

Thank you for the feedback! Perf is always an ongoing issue for us but I can say that we’ve recently allocated one of our senior engineers to take on more perf related issues. Something that really helps us out is if you could file reproducible steps that lead to your performance issue. This allows us to address the issues more readily. Please file your issues here: https://github.com/microsoft/vscode-cpptools/issues