Hi @ExceptionGit 👋

Thank you for this info!! Can you explain it a little more in-depth? Here is what I concluded, let me know where I am wrong:

• MS's C# extension only works with the VS Code product
• Samsung also provides a C# debugger (?)
• If you edit the launch.json file in your project, you can get C# debugging using the Samsung debugger (?)

Follow-up questions:

• Is this C# extension problem happening on Windows/Linux and not Mac? Or is it happening across all platforms?
• Is there a similar workaround for C++ projects to help C++ extension's Windows debugging does not work #71

Thanks again for sharing this workaround 👍

Hi @stripedpajamas 👋

* MS's C# extension only works with the VS Code product

MS's C# extension works everywhere, but debugger from this extension only works with the :
Visual Studio Code, Visual Studio or Visual Studio for Mac
dotnet/vscode-csharp#2846 (comment)
dotnet/vscode-csharp#2491 (comment)
dotnet/core#505

* Samsung also provides a C# debugger (?)

Yes! https://github.com/Samsung/netcoredbg/blob/master/README.md
NetCoreDbg is a managed code debugger with MI interface for CoreCLR. The debugger provides GDB/MI or VSCode Debug Adapter protocol and allows to debug .NET apps under .NET Core runtime.

* If you edit the launch.json file in your project, you can get C# debugging using the Samsung debugger (?)

Yes! Samsung/netcoredbg#1 (comment)

* Is this C# extension problem happening on Windows/Linux and not Mac? Or is it happening across all platforms?

All platforms..

* Is there a similar workaround for C++ projects to help #71

Maybe. I don't use c++, check this https://microsoft.github.io/debug-adapter-protocol/implementors/adapters/ , no alternative. May help: How To Debug MIEngine.md and PipeTransport.md

Awesome 👍

I will put this into a snippet on the Docs page for future reference. Thanks @ExceptionGit

It's great that there's a well documented issue for this. However, this is a deal breaker when it comes to Codium.

I can't expect my whole team to switch to using netcoredbg just because I want to run Codium (assuming I understand this solution correctly). It's a shame they forced the more official solution to only work with Code.

I'd prefer if this issue was highlighted in the README.md so others like me don't end up wasting some time on this issue.

I guess I'll have to stick to Code. Thanks for the work otherwise!

Thanks for trying it out @harvzor and thank you for your comment. I agree and will put a note in the README to hopefully save others from wasting any time 👍

Hi @harvzor
I think this problem is not in VSCodium or plugin omnisharp-vscode. Problem in Microsoft license dotnet/core#505 . VSCodium community is not obliged to keep track of all plugins/licenses/etc, if you don't read the license terms, this is your problem.

Microsoft .NET Core Debugger (vsdbg) is not an open source product! Please read https://aka.ms/VSCode-DotNet-DbgLicense or alt URL.


@stripedpajamas Due to license restrictions, some plugins/libs are not supported and fully work only in VSCode(proprietary binary from Microsoft) .. but this is obvious ..

As I am preparing to create a debugger extension for MonoDevelop based on Samsung debugger, I came across this thread (which of course is very valuable).

But I'd like to raise a concern that merely use pipeTransport settings as the first post indicated, might not fully resolve the licensing issue.

OmniSharp not only downloads Microsoft's debugger (vsdbg), but also downloads other supporting files (like vsdbg-ui). When pipeTransport is used, I suspect that vsdbg-ui is still used by OmniSharp, which can still lead to a licensing issue (vsdbg does check if it runs by a valid IDE, but vsdbg-ui does not). Maybe the ultimate solution is to patch OmniSharp to use netcoredbg instead of vsdbg-ui.

On Windows, trying to build netcoredbg requires VS 2017 Community.

I was able to build, but when call netcoredbg.exe I get

---------------------------
Microsoft Visual C++ Runtime Library
---------------------------
Debug Error!

Program: ...c\dotnet\netcoredbg\src\debug\netcoredbg\Debug\netcoredbg.exe

abort() has been called

(Press Retry to debug the application)

---------------------------
Abort   Retry   Ignore   
---------------------------

I was not able to build in Release(no target?) and cmake does not work (by default) with VS Build Tools.

So, debugging C# with vscodium on Windows requires Linux level power user skills and installing tracking software like VS 2017. And much of zeal to hope things will work, eventually....

@dzmitry-lahoda You can download binaries directly from GitHub, https://github.com/Samsung/netcoredbg/releases

What you got is expected as the debugger when launched would like to debug something but you don't give it the information. You might try to run netcoredbg --help if your goal is to verify whether you build it successfully.

Hi!
Unless I'm missing something, these instructions do eliminate the original issue: F5 now runs without errors.
But any breakpoints are ignored! The only way I can step through the code is by setting "stopAtEntry": true because all the breakpoints I set are simply ignored when starting the aforementionned debuging launch profile.

I'm on latest patched win10 x64 , vscodium, c# extension, dotnetcore sdk and samsung debugger relases

thanks in advance
ubidev

Is doing this ok?

#!/bin/node

const fs = require('fs');

var filename = '/usr/lib/code/package.json'
var package_data = require(filename)

package_data.name = 'Code'
package_data.desktopName = 'code-url-handler.desktop'

fs.writeFileSync(filename, JSON.stringify(package_data));

var filename = '/usr/lib/code/product.json'
var product_data = require(filename)
product_data.nameShorta = 'Code'
product_data.nameLong = 'Visual Studio Code'
product_data.applicationName = 'code'

fs.writeFileSync(filename, JSON.stringify(product_data));

Is doing this ok?

#!/bin/node

const fs = require('fs');

var filename = '/usr/lib/code/package.json'
var package_data = require(filename)

package_data.name = 'Code'
package_data.desktopName = 'code-url-handler.desktop'

fs.writeFileSync(filename, JSON.stringify(package_data));

var filename = '/usr/lib/code/product.json'
var product_data = require(filename)
product_data.nameShorta = 'Code'
product_data.nameLong = 'Visual Studio Code'
product_data.applicationName = 'code'

fs.writeFileSync(filename, JSON.stringify(product_data));

Tried this on vscodium and microsoft/vscode but it did not work. vsdbg requires microsoft build releases which contain signing keys or some other licensing DRM.

Until they make vsdbg open source, the only way is to use netcoredbg from Samsung which has issues of its own.

I'm not sure if things have changed since this workaround was first captured, but unfortunately the instructions don't work for me on Manjaro Linux!

I added the "pipeTransport" options, using /usr/bin/netcoredbg as the "debuggerPath" as I had installed netcoredbg through the AUR. See my full launch.json further down.

But when I debug by pressing F5, nothing seems to happen. The debug console appears, with a message at the top that says Starting: "bash" -c "/usr/bin/netcoredbg --interpreter=vscode", before showing any output from my program. But I don't get any terminal window where I can interact with my program, which is what normally happens when using vsdbg (the official debugger), with the official VS Code.

Am I missing something? Or does this workaround no longer work?

launch.json

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": ".NET Core Launch (console)",
            "type": "coreclr",
            "request": "launch",
            "preLaunchTask": "build",
            "program": "${workspaceFolder}/bin/Debug/net6.0/HelloWorld.dll",
            "args": [],
            "cwd": "${workspaceFolder}",
            "console": "integratedTerminal",
            "internalConsoleOptions": "openOnSessionStart",
            "stopAtEntry": false,
            "pipeTransport": {
                "pipeCwd": "${workspaceFolder}",
                "pipeProgram": "bash",
                "pipeArgs": [
                    "-c"
                ],
                "debuggerPath": "/usr/bin/netcoredbg",
                "quoteArgs": true
            },
        },
        {
            "name": ".NET Core Attach",
            "type": "coreclr",
            "request": "attach"
        }
    ]
}

Am I missing something? Or does this workaround no longer work?

See "console": "integratedTerminal" or maybe del

{
    "name": ".NET Core Attach",
    "type": "coreclr",
    "request": "attach"
}

Or install omnisharp-vscode+netcoredbg extension (open-vsx.org) [src]

Okay, so I tried this on a fresh machine with Manjaro. Installed VS Code and VS Codium (both v1.68). On VS Code I installed the official extension, and on VS Codium I installed the omnisharp-vscode+netcoredbg extension you linked (both v1.25). I tried debugging the same project in each one. I expect to get a debug terminal where I can interact with my program (e.g., so I can respond to Console.ReadLine()).

VS Code

launch.json

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": ".NET Core Launch (console)",
            "type": "coreclr",
            "request": "launch",
            "preLaunchTask": "build",
            "program": "${workspaceFolder}/bin/Debug/net6.0/HelloWorld.dll",
            "args": [],
            "cwd": "${workspaceFolder}",
            "console": "integratedTerminal",
            "internalConsoleOptions": "neverOpen",
            "stopAtEntry": false
        }
    ]
}

Screenshot

Project gets built in one terminal. As required, a separate terminal opens and runs vsdbg, and I can interact with the application in this terminal.

VS Codium

launch.json

Notice that my debuggerPath option points to the netcoredbg binary installed with the extension, like you suggest.

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": ".NET Core Launch (console)",
            "type": "coreclr",
            "request": "launch",
            "preLaunchTask": "build",
            "program": "${workspaceFolder}/bin/Debug/net6.0/HelloWorld.dll",
            "args": [],
            "cwd": "${workspaceFolder}",
            "console": "integratedTerminal",
            "internalConsoleOptions": "openOnSessionStart",
            "stopAtEntry": false,
            "pipeTransport": {
                "pipeCwd": "${workspaceFolder}",
                "pipeProgram": "bash",
                "pipeArgs": [
                    "-c"
                ],
                "debuggerPath": "/home/murchu27/.vscode-oss/extensions/muhammad-sammy.csharp-1.25.0/.debugger/netcoredbg/netcoredbg",
                "quoteArgs": true
            }
        }
    ]
}

Screenshot

Project gets built in one terminal. No new terminal opens to launch netcoredbg, so I can't interact with the program

Analysis

Since vsdbg seems to be using some pipe files or something like that in /tmp, I checked to see if netcoredbg was doing something similar. Sure enough, the below files appeared after choosing "Run > Start Debugging" in VS Codium.

❯ ls /tmp/clr-debug-pipe*
/tmp/clr-debug-pipe-55252-2258222-in  /tmp/clr-debug-pipe-55252-2258222-out  /tmp/clr-debug-pipe-55260-2258227-in  /tmp/clr-debug-pipe-55260-2258227-out

I thought maybe I could troubleshoot this by connecting to these pipes with netcoredbg manually, similar to what VS Code does automatically for vsdbg. But I couldn't figure out how to use them. vsdbg is using a --connection command line option to connect to its pipes, and netcoredbg doesn't have this option.

Any ideas how I can properly debug this with netcoredbg? If this is veering into the realm of a new issue, I'm happy to open one. Just wanted to start here since people here have obviously gotten the debugger working for them.

Thanks @murchu27 👍

From your issue muhammadsammy/free-vscode-csharp#38, I think "console": "integratedTerminal" workaround doesn't work anymore Samsung/netcoredbg#80 (comment). Because of this, it is impossible to use Console.Read*.

Handling stdin in VSCode is much more complicated. First VSCode need to support since now it pass vscode protocol commands to application stdin and NCDB get them from it.
CLI protocol works completely different way.

If you want, you can check this IDE https://github.com/eclipse-theia/theia, maybe it works there.