Update pipeTransport options to be more robust #72
Conversation
|
@granitrocky hello and thanks for mentioning me in the other issue. I think I am missing something as I could not get the debugger to stop at the breakpoint with a vsix built from your repo. Before I start asking questions about what am I doing wrong, can you stop at the breakpoint in Program.cs with your vsix in this simple dotnet8 helloworld app? https://github.com/dgokcin/dotnet-cursor-debugging-with-breakpoints |
|
@dgokcin For some reason the netcoredbg in your repo doesn't work on my system, so this config works with a breakpoint: {
"name": ".NET Core Launch (console)",
"type": "coreclr",
"request": "launch",
"preLaunchTask": "build",
"program": ",${workspaceFolder}/bin/Debug/net8.0/dotnet-cursor-debugging-with-breakpoints.dll",
"args": [],
"cwd": "${workspaceFolder}",
"stopAtEntry": false,
"console": "internalConsole",
"internalConsoleOptions": "openOnSessionStart",
"logging": {
"diagnosticsLog": {
"protocolMessages": true
}
},
"pipeTransport": {
"pipeCwd": "${workspaceFolder}",
"pipeProgram": "dotnet",
"pipeArgs": [
"${workspaceFolder}/bin/Debug/net8.0/dotnet-cursor-debugging-with-breakpoints.dll",
],
"quoteArgs": true
},
}, |
|
@granitrocky very interesting. For me, the config you shared gives me an error saying the debugger path is required, although I can see that the .vsix I have built have your latest changes from this branch. 
Downloading the latest release artifact from https://github.com/Samsung/netcoredbg/releases for my mac and re-adding the debuggerPath argument to the launch.json gives me the following error where I see the hello world for the first time in the console output but still can not stop at the breakpoint 
|
|
@dgokcin The pipeTransport error makes me think that maybe it's the wrong extension? Did you make sure to install the correct |
|
@granitrocky Although I think I am building and installing the
I know that the required debugger option has been removed by you in your last commit which makes me think something is still not correct. Any idea what am I doing wrong? I would be happy to share logs/screenshots/diagostics. Thanks! |
|
That is odd. Are you cloning from master on my fork? Maybe I should do the same to verify. |
|
@granitrocky yeah master on your fork. |
|
@dgokcin I just built the plugin directly from master and was able to hit a breakpoint in your test repo, and didn't get yelled at about the I am now seeing that I think you are using VSCode and not VSCodium. I don't know if the plugin works on vscode differently. EDIT: I actually was able to get the breakpoints working in VSCode just by having the Microsoft C# extensions as well as this extension active. The editor flagged {
"name": ".NET Core Launch (console)",
"type": "coreclr",
"request": "launch",
"preLaunchTask": "build",
"program": "${workspaceFolder}/bin/Debug/net8.0/dotnet-cursor-debugging-with-breakpoints.dll",
"args": [],
"cwd": "${workspaceFolder}",
"stopAtEntry": false,
"console": "internalConsole",
"internalConsoleOptions": "openOnSessionStart",
"logging": {
"diagnosticsLog": {
"protocolMessages": true
}
},
"pipeTransport": {
"pipeCwd": "${workspaceFolder}",
"pipeProgram": "dotnet",
"pipeArgs": [
"${workspaceFolder}/bin/Debug/net8.0/dotnet-cursor-debugging-with-breakpoints.dll",
],
"quoteArgs": true
},
}, |
|
I am using the extension with cursor.sh which is also a vscode fork similar to codium. I will try using the plugin with codium. In the meantime could you please also try debugging the same repo with cursor? Maybe we can find a solution that works both on cursor and codium which will make your PR even more flexible. On codium do you only install this extension or you need the microsoft c# extension as well? I had to install them both in a specific order (first microsoft than this one) to get to the point where I am currently at. |
|
@dgokcin No need for the Microsoft extensions in vscodium. Just make sure dotnet is on PATH and install this extension. |
|
@granitrocky no luck with codium on an m2 mac. Were you able to run the extension on cursor? |
This update builds on #68 and lets the user launch the default debugger instead of needing to specify where exactly it is.
Also separates command line arguments for the debugger and the launched executable, allowing you to pass additional parameters. Example configuration:
This will launch the debugger as
/var/home/granitrocky/.vscode-oss/extensions/muhammad-sammy.csharp-2.31.19/.debugger/netcoredbg/netcoredbg --interpreter=vscode -- /usr/bin/godot -e{ "name": "🕹 Debug Game", "type": "coreclr", "request": "launch", "preLaunchTask": "build", "program": "", "cwd": "${workspaceFolder}", "internalConsoleOptions": "openOnSessionStart", "pipeTransport": { "pipeCwd": "${workspaceFolder}", "pipeProgram": "/usr/bin/godot", "pipeArgs": [ "-e" ] } }And an example WITH a specific debugger:
THIS will launch the debugger as
/opt/netcoredbg/netcoredbg --interpreter=vscode -- /usr/bin/godot -e{ "name": "🕹 Debug Game", "type": "coreclr", "request": "launch", "preLaunchTask": "build", "program": "", "cwd": "${workspaceFolder}", "internalConsoleOptions": "openOnSessionStart", "pipeTransport": { "pipeCwd": "${workspaceFolder}", "pipeProgram": "/usr/bin/godot", "pipeArgs": [ "-e" ], "depuggerPath": "/opt/netcoredbg/netcoredbg", "debuggerArgs": [ "--interpreter=vscode", "--", ], "quoteArgs": true } }