muhammadsammy / free-vscode-csharp

Free/Libre fork of the official C# extension for vscode
https://open-vsx.org/extension/muhammad-sammy/csharp
Other
110 stars 10 forks source link

Update pipeTransport options to be more robust #72

Closed granitrocky closed 2 weeks ago

granitrocky commented 1 month ago

This update builds on https://github.com/muhammadsammy/free-vscode-csharp/pull/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
        }
      }
dgokcin commented 1 month ago

@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

granitrocky commented 1 month ago

@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
          },
      },
dgokcin commented 1 month ago

@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.

image image

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

image
granitrocky commented 1 month ago

@dgokcin The pipeTransport error makes me think that maybe it's the wrong extension? Did you make sure to install the correct .vsix file?

dgokcin commented 1 month ago

@granitrocky Although I think I am building and installing the .vsix correctly, I am sure that something is not right. Here are my steps:

image image

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!

granitrocky commented 1 month ago

That is odd. Are you cloning from master on my fork? Maybe I should do the same to verify.

dgokcin commented 1 month ago

@granitrocky yeah master on your fork.

granitrocky commented 1 month ago

@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 debuggerPath missing.

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. Could you try this extension on VSCodium instead?

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 debuggerPath as necessary, but it still ran. At this point I think it may be a mac specific issue.

{
        "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
          },
      },
dgokcin commented 1 month ago

@granitrocky

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.

granitrocky commented 1 month ago

@dgokcin No need for the Microsoft extensions in vscodium. Just make sure dotnet is on PATH and install this extension.

dgokcin commented 1 month ago

@granitrocky no luck with codium on an m2 mac. Were you able to run the extension on cursor?