C# .NET Unit Test Debugging?

Discussions
1

I am able to debug my application using Samsung’s netcoredbg (following the instructions in GitHub - dgokcin/dotnet-cursor-debugging-with-breakpoints), but I haven’t been able to figure out how to debug unit tests in this same way.

Ideally I’d like to just be able to Right Click > Debug Test in the Test Explorer, but I haven’t been able to figure out how to configure the Test Explorer to use netcoredbg instead of Microsoft’s debugger. It just shows the same error message that I got before switching my application launch to use netcoredbg.

“.NET Debugging is supported only in Microsoft versions of VS Code. See Microsoft .NET Core Debugger licensing and Microsoft Visual Studio Code · dotnet/vscode-csharp Wiki · GitHub for more information.”

Does anyone know how to do this, or have a workaround that doesn’t involve switching between Cursor and VSCode/VisualStudio?

Screenshot 2025-01-13 at 9.22.18 AM
Screenshot 2025-01-13 at 9.22.18 AM518×190 19.9 KB

2

Could not get it to work, but i have rider open simultaneously most of the time which is pretty light compared to VS. For just building or running tests, dotnet run and dotnet test do great though.

Debugging would be great if possible, but would prefer official tooling in that case.

3

Have you figured out how to do this by any chance? :slight_smile:

4

No unfortunately… This is still the only reason I still keep VisualStudio/VSCode around instead of using Cursor exclusively.

5

Thanks for sharing… I’ll stop my attempts to debug tests in Cursor then. Indeed, running several IDEs is annoying.

6

I was able to do it but it’s very convoluted, so I’m still trying to find a better way.

Basically follow this guide: Dotnet debugging with VSCodium on Linux - Some tech notes

You basically launch the test with VSTEST_HOST_DEBUG set to 1 which makes the test wait for a debugger to attach to execute and then launch the given configuration.

But the configuration as proposed gave me errors and was only able to make it work with

"processId": "${command:pickProcess}",

So I have to edit the processId manually each time…

Here’s my configuration example

        {
            "name": ".NET Test Attach (Given ID)",
            "type": "coreclr",
            "request": "attach",
            "processId": "100836",
            "pipeTransport": {
                "debuggerPath": "netcoredbg.exe",
                "windows": {
                    "pipeCwd": "${workspaceFolder}",
                    "pipeProgram": "bash",
                    "pipeArgs": [
                        "-c"
                    ],
                    "debuggerArgs": [
                        "--interpreter=vscode",
                    ],
                    "quoteArgs": true
                },
            }
        },
1 Like
7

Thank you, that worked!

I was able to get it working on my M2 Mac with my netcoredbg compiled from source (following the instructions from my original post), with this configuration:

        {
            "name": ".NET Core Attach (console)",
            "type": "coreclr",
            "processId": "${command:pickProcess}",
            "request": "attach",
            "console": "integratedTerminal",
            "stopAtEntry": false,
            "internalConsoleOptions": "openOnSessionStart",
            "pipeTransport": {
                "pipeCwd": "${workspaceFolder}",
                "pipeProgram": "bash",
                "pipeArgs": ["-c"],
                "debuggerPath": "/Users/yourUsername/.local/netcoredbg",
                "quoteArgs": true
            }
        }

The command:pickProcess seems to work, so I can just choose the process from the list after running the test with VSTEST_HOST_DEBUG set to 1!

Obviously not ideal, but this will work for now!

8

One additional note:

When you have multiple test projects (I have 4 in my current codebase), dotnet test will spawn an instance of testhost.dll for each project, and wait for each of them to be attached to individually before the command will complete.

9

Ok, that’s interesting, the pickProcess might just be broken on Windows

The error I got on windows is:

“stderr: your 131072x1 screen size is bogus. expect trouble
your 131072x1 screen size is bogus. expect trouble”

10

Ok, I got some news. I found this extension that has not received updates for some time now but does work on VS Code (apart from a few bugs): GitHub - formulahendry/vscode-dotnet-test-explorer: .NET Core Test Explorer for Visual Studio Code

But looking at the code got me intrigued, and I decided to fork it and try to add the support for the pipeTransport and I got it working:

image
image1914×1028 82.4 KB

For anyone interested, here is the packaged extension with my changes (check what I changed in the commit history): Release Pre-Release 0.7.9 · jorgepsmatos/vscode-dotnet-test-explorer · GitHub

3 Likes