Add zed-netcoredbg to csharp extension, add runnables

[Tiggilyboo]

This PR adds debugging support #12 as originally implemented by https://github.com/qwadrox/zed-netcoredbg I merged this code over for debug use. It uses netcoredbg: https://github.com/Samsung/netcoredbg

My PR adds runnables which detect test files, so test fixtures and individual tests can be run or debugged.

There is however one caveat, I can't seem to find a way to properly attach to the running test pid as we cannot inspect the process from within the extension. As seen in the screenshot below, the user can read and manually attach to the process id in the current implementation until a better solution is found. The only other way I can think of at the moment is to run the tests and output a temporary file which can be read by the extension, or somehow get the tcp connection working.

Open to other ideas, but at least this is one step forward to integrated test runnables from the csharp extension...

From my git commit log for more details:

• Use extension from https://github.com/qwadrox/zed-netcoredbg to have basic debug functionality with DAP and download netcoredbg for the running platform.
• Add runnables and tasks to debug from test files. Captures for nunit, xunit, vstest. Not strict, purely functional (does not pair keywords) to test framework.
• Currently unable to fully attach to runnable, but starts the vstest process so that it can be easily attached with PID listed in console

[cla-bot]

Thank you for your pull request and welcome to our community. We could not parse the GitHub identity of the following contributors: Simon Willshire.
This is most likely caused by a git client misconfiguration; please make sure to:

1. check if your git client is configured with an email to sign commits git config --list | grep email
2. If not, set it up using git config --global user.email email@example.com
3. Make sure that the git commit email is configured in your GitHub account settings, see https://github.com/settings/emails

[cla-bot]

Thank you for your pull request and welcome to our community. We could not parse the GitHub identity of the following contributors: Simon Willshire.
This is most likely caused by a git client misconfiguration; please make sure to:

1. check if your git client is configured with an email to sign commits git config --list | grep email
2. If not, set it up using git config --global user.email email@example.com
3. Make sure that the git commit email is configured in your GitHub account settings, see https://github.com/settings/emails

[Sathiyaraman-M]

Just wanted to mention that netcoredbg isn't officially supported in MacOS for ARM architecture.

[Tiggilyboo]

Just wanted to mention that netcoredbg isn't officially supported in MacOS for ARM architecture.

Yea, was made aware of this asking permission from the zed-netcoredbg repository: qwadrox/zed-netcoredbg#6 (comment)

Currently the extension pulls from the netcoredbg releases which builds this, but ideally we do not pull from there...

Is it a hard requirement that the debugging extension works with all zed targets? ie. Get this one through with a "MacOS aarch64 is not supported at the moment"?

[Sathiyaraman-M]

Is it a hard requirement that the debugging extension works with all zed targets? ie. Get this one through with a "MacOS aarch64 is not supported at the moment"?

As long as it falls back gracefully in MacOS ARM64 devices, it should be fine. Also having an explicit note on this somewhere in the extension README would be nice.

[brendanmckenzie]

Not sure if it helps, but I've created a fork of the Samsung repo that keeps itself in sync with the upstream and automatically triggers builds of new releases. It builds for linux-x64, linux-arm64, macos-x64, macos-arm64 and win64.

See https://github.com/brendanmckenzie/netcoredbg/releases

[cla-bot]

We require contributors to sign our Contributor License Agreement, and we don't have @Tiggilyboo on file. You can sign our CLA at https://zed.dev/cla. Once you've signed, post a comment here that says '@cla-bot check'.

[cla-bot]

We require contributors to sign our Contributor License Agreement, and we don't have @Tiggilyboo on file. You can sign our CLA at https://zed.dev/cla. Once you've signed, post a comment here that says '@cla-bot check'.

[Tiggilyboo]

Have sorted the faff with git email and signed the cla... Hopefully.

@cla-bot check

[cla-bot]

We require contributors to sign our Contributor License Agreement, and we don't have @Tiggilyboo on file. You can sign our CLA at https://zed.dev/cla. Once you've signed, post a comment here that says '@cla-bot check'.

[cla-bot]

The cla-bot has been summoned, and re-checked this pull request!

[Dakota-LM]

Any eta on this getting merged? I'm literally just cloning zed-netcoredbg locally and importing it as a dev extension lol

[cm4ker]

https://github.com/MattParkerDev/sharpdbg/ - I found this. Perhaps it's worth looking here as well.

[kevin-mueller]

This is super cool! The runnables.scm thing is very fancy, had no idea Zed supports that.

For those interested, I have forked my own version of this repository, integrating some of the things proposed by this PR. I also added a bunch of other stuff:

https://github.com/kevin-mueller/zed-csharp

@Tiggilyboo I also beat my head against a wall, trying to figure out how to automatically attach the debugger to a test process. In the end, I got it working, but it's a bit hacky.

I basically deferred the building of a csproj to the run_dap_locator function, because that's the only place where the $ZED variables are actually resolved. Then I could just launch the .dll via the netcoredbg config.

[Tiggilyboo]

Not entirely sure what the next steps are here - I can resolve this current conflict, but the current state is still a bit clunky without the upstream Zed API giving us more filesystem operations (we can't find the csproj without a solution like @kevin-mueller has implemented - executes a script in bash or pwsh).

As for the netcoredbg sourcing, if we leave it up to the user to install? I'm not super keen on not providing all targets from unofficial sources.
This would return an error in the zed log stating that the netcoredbg binary could not be found.

[GustavEikaas]

@Tiggilyboo for the netcoredbg sourcing; the new version being released soon will have the macos arm target included Samsung/netcoredbg#174 (comment)

As others have mentioned SharpDbg is another alternative for an OSS coreclr debugger, it is being published as a dotnet tool for easy install, would be similiar install method to roslyn-language-server.

Not many releases yet but author literally just added support for it
https://www.nuget.org/packages/SharpDbg.Cli

[GustavEikaas]

Total Zed and Rust noob here, but reading through this PR it looks like this currently handles the VSTest path only?

Just wanted to provide some context in case it's useful for future work — not criticism of the approach here, this PR is awesome.

There are currently two test platforms in .NET:

• VSTest
• MTP (Microsoft Testing Platform)

If support for MTP is ever added, I think there are a couple of additional pieces that would be needed:

1. Detect whether the project is using MTP or VSTest. One way to do that is:

dotnet msbuild -getProperty:IsTestingPlatformApplication

If stdout is true then it's an MTP project.

2. For MTP, it should be possible to build the project, resolve the test assembly path via TargetPath, and issue a DAP launch request against the test executable/assembly rather than using the VSTest attach flow.

For example:

dotnet msbuild -getProperty:TargetPath

which returns the path to the built test assembly (assuming the active configuration, typically Debug).

3. Test filtering would need different handling since the filter syntax differs from VSTest.

One interesting thing about MTP is that it also supports a server/RPC mode, which could potentially allow test execution and result collection without relying on output parsing:

https://github.com/GustavEikaas/easy-dotnet-server/blob/main/EasyDotnet.IDE/TestRunner/Adapters/MTP/RPC/MtpClient.cs#L59

Not suggesting any of this belongs in this PR, but I thought it might be useful context for anyone looking at test debugging support longer-term.