Add zed-netcoredbg to csharp extension, add runnables by Tiggilyboo · Pull Request #43 · zed-extensions/csharp

Tiggilyboo · 2025-12-22T22:09:50Z

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 · 2025-12-22T22:09:54Z

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:

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

cla-bot · 2025-12-22T22:17:16Z

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:

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

Sathiyaraman-M · 2025-12-27T10:17:48Z

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

Tiggilyboo · 2025-12-28T18:07:57Z

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 · 2025-12-29T04:45:33Z

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 · 2026-01-07T00:52:04Z

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 · 2026-02-03T08:14:09Z

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

- 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 · 2026-02-03T08:18:12Z

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 · 2026-02-03T08:19:10Z

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

@cla-bot check

cla-bot · 2026-02-03T08:19:12Z

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 · 2026-02-03T08:19:14Z

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

Dakota-LM · 2026-02-05T23:10:00Z

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

cm4ker · 2026-02-06T03:30:51Z

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

kevin-mueller · 2026-02-13T20:19:47Z

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 · 2026-06-16T21:27:05Z

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 · 2026-06-22T07:59:39Z

@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 · 2026-06-22T08:36:08Z

+ }
+ }
+
+ fn dap_locator_create_scenario(


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:
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.
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).
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.

Tiggilyboo · 2025-12-22T22:09:50Z

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 · 2025-12-22T22:09:54Z

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:

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

cla-bot · 2025-12-22T22:17:16Z

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:

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

Sathiyaraman-M · 2025-12-27T10:17:48Z

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

Tiggilyboo · 2025-12-28T18:07:57Z

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 · 2025-12-29T04:45:33Z

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 · 2026-01-07T00:52:04Z

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 · 2026-02-03T08:14:09Z

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

- 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 · 2026-02-03T08:18:12Z

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 · 2026-02-03T08:19:10Z

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

@cla-bot check

cla-bot · 2026-02-03T08:19:12Z

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 · 2026-02-03T08:19:14Z

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

Dakota-LM · 2026-02-05T23:10:00Z

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

cm4ker · 2026-02-06T03:30:51Z

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

kevin-mueller · 2026-02-13T20:19:47Z

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 · 2026-06-16T21:27:05Z

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 · 2026-06-22T07:59:39Z

@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 · 2026-06-22T08:36:08Z

+ }
+ }
+
+ fn dap_locator_create_scenario(


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:
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.
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).
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.

Tiggilyboo · 2025-12-22T22:09:50Z

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 · 2025-12-22T22:09:54Z

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:

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

cla-bot · 2025-12-22T22:17:16Z

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:

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

Sathiyaraman-M · 2025-12-27T10:17:48Z

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

Tiggilyboo · 2025-12-28T18:07:57Z

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 · 2025-12-29T04:45:33Z

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 · 2026-01-07T00:52:04Z

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 · 2026-02-03T08:14:09Z

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

- 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 · 2026-02-03T08:18:12Z

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 · 2026-02-03T08:19:10Z

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

@cla-bot check

cla-bot · 2026-02-03T08:19:12Z

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 · 2026-02-03T08:19:14Z

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

Dakota-LM · 2026-02-05T23:10:00Z

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

cm4ker · 2026-02-06T03:30:51Z

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

kevin-mueller · 2026-02-13T20:19:47Z

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 · 2026-06-16T21:27:05Z

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 · 2026-06-22T07:59:39Z

@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 · 2026-06-22T08:36:08Z

+ }
+ }
+
+ fn dap_locator_create_scenario(


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:
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.
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).
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.

Tiggilyboo · 2025-12-22T22:09:50Z

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 · 2025-12-22T22:09:54Z

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:

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

cla-bot · 2025-12-22T22:17:16Z

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:

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

Sathiyaraman-M · 2025-12-27T10:17:48Z

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

Tiggilyboo · 2025-12-28T18:07:57Z

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 · 2025-12-29T04:45:33Z

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 · 2026-01-07T00:52:04Z

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 · 2026-02-03T08:14:09Z

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

- 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 · 2026-02-03T08:18:12Z

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 · 2026-02-03T08:19:10Z

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

@cla-bot check

cla-bot · 2026-02-03T08:19:12Z

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 · 2026-02-03T08:19:14Z

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

Dakota-LM · 2026-02-05T23:10:00Z

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

cm4ker · 2026-02-06T03:30:51Z

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

kevin-mueller · 2026-02-13T20:19:47Z

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 · 2026-06-16T21:27:05Z

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 · 2026-06-22T07:59:39Z

@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 · 2026-06-22T08:36:08Z

+ }
+ }
+
+ fn dap_locator_create_scenario(


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:
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.
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).
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.

Tiggilyboo · 2025-12-22T22:09:50Z

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 · 2025-12-22T22:09:54Z

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:

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

cla-bot · 2025-12-22T22:17:16Z

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:

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

Sathiyaraman-M · 2025-12-27T10:17:48Z

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

Tiggilyboo · 2025-12-28T18:07:57Z

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 · 2025-12-29T04:45:33Z

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 · 2026-01-07T00:52:04Z

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 · 2026-02-03T08:14:09Z

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

- 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 · 2026-02-03T08:18:12Z

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 · 2026-02-03T08:19:10Z

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

@cla-bot check

cla-bot · 2026-02-03T08:19:12Z

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 · 2026-02-03T08:19:14Z

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

Dakota-LM · 2026-02-05T23:10:00Z

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

cm4ker · 2026-02-06T03:30:51Z

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

kevin-mueller · 2026-02-13T20:19:47Z

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 · 2026-06-16T21:27:05Z

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 · 2026-06-22T07:59:39Z

@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 · 2026-06-22T08:36:08Z

+ }
+ }
+
+ fn dap_locator_create_scenario(


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:
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.
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).
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.

Tiggilyboo · 2025-12-22T22:09:50Z

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 · 2025-12-22T22:09:54Z

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:

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

cla-bot · 2025-12-22T22:17:16Z

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:

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

Sathiyaraman-M · 2025-12-27T10:17:48Z

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

Tiggilyboo · 2025-12-28T18:07:57Z

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 · 2025-12-29T04:45:33Z

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 · 2026-01-07T00:52:04Z

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 · 2026-02-03T08:14:09Z

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

- 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 · 2026-02-03T08:18:12Z

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 · 2026-02-03T08:19:10Z

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

@cla-bot check

cla-bot · 2026-02-03T08:19:12Z

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 · 2026-02-03T08:19:14Z

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

Dakota-LM · 2026-02-05T23:10:00Z

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

cm4ker · 2026-02-06T03:30:51Z

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

kevin-mueller · 2026-02-13T20:19:47Z

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 · 2026-06-16T21:27:05Z

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 · 2026-06-22T07:59:39Z

@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 · 2026-06-22T08:36:08Z

+ }
+ }
+
+ fn dap_locator_create_scenario(


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:
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.
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).
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.

Tiggilyboo · 2025-12-22T22:09:50Z

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 · 2025-12-22T22:09:54Z

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:

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

cla-bot · 2025-12-22T22:17:16Z

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:

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

Sathiyaraman-M · 2025-12-27T10:17:48Z

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

Tiggilyboo · 2025-12-28T18:07:57Z

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 · 2025-12-29T04:45:33Z

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 · 2026-01-07T00:52:04Z

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 · 2026-02-03T08:14:09Z

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

- 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 · 2026-02-03T08:18:12Z

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 · 2026-02-03T08:19:10Z

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

@cla-bot check

cla-bot · 2026-02-03T08:19:12Z

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 · 2026-02-03T08:19:14Z

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

Dakota-LM · 2026-02-05T23:10:00Z

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

cm4ker · 2026-02-06T03:30:51Z

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

kevin-mueller · 2026-02-13T20:19:47Z

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 · 2026-06-16T21:27:05Z

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 · 2026-06-22T07:59:39Z

@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 · 2026-06-22T08:36:08Z

+ }
+ }
+
+ fn dap_locator_create_scenario(


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:
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.
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).
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.

Tiggilyboo · 2025-12-22T22:09:50Z

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 · 2025-12-22T22:09:54Z

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:

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

cla-bot · 2025-12-22T22:17:16Z

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:

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

Sathiyaraman-M · 2025-12-27T10:17:48Z

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

Tiggilyboo · 2025-12-28T18:07:57Z

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 · 2025-12-29T04:45:33Z

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 · 2026-01-07T00:52:04Z

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 · 2026-02-03T08:14:09Z

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

- 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 · 2026-02-03T08:18:12Z

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 · 2026-02-03T08:19:10Z

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

@cla-bot check

cla-bot · 2026-02-03T08:19:12Z

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 · 2026-02-03T08:19:14Z

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

Dakota-LM · 2026-02-05T23:10:00Z

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

cm4ker · 2026-02-06T03:30:51Z

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

kevin-mueller · 2026-02-13T20:19:47Z

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 · 2026-06-16T21:27:05Z

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 · 2026-06-22T07:59:39Z

@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 · 2026-06-22T08:36:08Z

+ }
+ }
+
+ fn dap_locator_create_scenario(


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:
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.
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).
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.

Tiggilyboo mentioned this pull request Dec 22, 2025
Publish extension qwadrox/zed-netcoredbg#6
Closed

Tiggilyboo force-pushed the feature/netcoredbg-and-runnables branch from caf692f to 05e68e6Compare December 22, 2025 22:17

Tiggilyboo force-pushed the feature/netcoredbg-and-runnables branch from 05e68e6 to a78b794Compare February 3, 2026 08:14

Tiggilyboo force-pushed the feature/netcoredbg-and-runnables branch from a78b794 to 43052c0Compare February 3, 2026 08:18

Merge branch 'main' into feature/netcoredbg-and-runnables
b452799

cla-botBot added the cla-signed label Feb 3, 2026

Tiggilyboo marked this pull request as ready for review February 3, 2026 08:21

reflectronic self-assigned this Feb 4, 2026

Merge branch 'main' into feature/netcoredbg-and-runnables
e715c5c

Merge branch 'main' into feature/netcoredbg-and-runnables
91d337d

MrSubidubi mentioned this pull request May 29, 2026
Add NetCoreDbg (.NET Core debugger) extension zed-industries/extensions#5212
Closed

GustavEikaas reviewed Jun 22, 2026
View reviewed changes

Gambl3r08 mentioned this pull request Jul 30, 2026
Add netcoredbg debug adapter, dotnet locator, and runnables #95
Open

Gambl3r08 mentioned this pull request Aug 6, 2026
Add dotnet extension zed-industries/extensions#7098
Open
1 task