`start_debugging` with `testName` parameter produces broken config for C#/.NET (coreclr) — `createTestDebugConfig` is unreachable dead code

[mikejohnstonPremierinc]

Summary

When calling start_debugging with the testName parameter on a C#/.NET test file, the extension generates a broken debug configuration that attempts to launch the .cs file directly as a program instead of running dotnet test --filter. The correct code path (createTestDebugConfig for coreclr) exists but is unreachable dead code.

This is a regression introduced by PR #55 (v1.1.1) which removed the testing.debugCurrentFile special case for coreclr to fix ASP.NET app debugging (#54), but did not address the testName code path that was left behind.

Environment

• VS Code Version: 1.101.2
• DebugMCP Version: 1.1.4
• OS: Windows 11
• C# Extension: ms-dotnettools.csharp v2.140.8
• Project Type: NUnit test project (.NET 9.0)
• Debug Configuration: coreclr

Root Cause — Source Code Analysis

File: src/utils/debugConfigurationManager.ts

Line ~108:

if (testName && detectedLanguage !== 'coreclr') {
    return await this.createTestDebugConfig(detectedLanguage, fileFullPath, cwd, testName);
}

When testName is provided AND detectedLanguage === 'coreclr':

This condition is FALSE (because of !== 'coreclr')
createTestDebugConfig is skipped entirely
Execution falls through to the default config which returns: { type: 'coreclr', request: 'launch', program: fileFullPath } — attempting to launch a .cs file as a program
Lines ~341-360 — DEAD CODE:

case 'coreclr':
    return {
        type: 'coreclr', request: 'launch',
        name: `DebugMCP .NET Test: ${testName}`,
        program: 'dotnet',
        args: ['test', '--filter', `FullyQualifiedName~${testName}`, '--no-build'],
        console: 'integratedTerminal', cwd: cwd, stopAtEntry: false
    };

This case 'coreclr' inside createTestDebugConfig is correct and would work — but it is never reached because the if condition on line 108 excludes coreclr from calling createTestDebugConfig.

How PR #55 (v1.1.1) Caused This
Before v1.1.1, coreclr had a special-case path using testing.debugCurrentFile. PR #55 (commit 825ed44 — "Remove special-case coreclr launch path") correctly removed that to fix ASP.NET app debugging. However, this left the testName code path broken:

• Pre-v1.1.1: testing.debugCurrentFile handled coreclr tests (partially worked)
• Post-v1.1.1: testing.debugCurrentFile removed, but if (testName && detectedLanguage !== 'coreclr') still prevents createTestDebugConfig from being reached for coreclr

Steps to Reproduce

1. Open an NUnit/xUnit/MSTest project in VS Code
2. Set a breakpoint in a test method
3. Call start_debugging with parameters:
4. filePath: path to the .cs test file
5. testName: name of the test method (e.g., "MyTestMethod")
6. Expected: DebugMCP creates a dotnet test --filter FullyQualifiedName~MyTestMethod config and debugs the test
7. Actual: Error — tries to launch the .cs file directly: "Unable to start program '[path].cs'"

Proposed Fix
Change line ~108 from:

if (testName && detectedLanguage !== 'coreclr') {

to

if (testName) {

This allows createTestDebugConfig to be called for all languages including coreclr, making the existing case 'coreclr' code reachable. The dotnet test --filter config it generates is correct.

Workaround
Using the configurationName parameter (added in v1.0.8) to reference a named launch.json configuration that manually specifies the dotnet test --filter command bypasses the broken auto-detection entirely.

Related Issues
#54 — PR #55 introduced this regression while fixing ASP.NET app debugging
#11 — Separate issue about MCP tools not detecting external C# debug sessions

[ozzafar]

thanks again @mikejohnstonPremierinc!
this also should be resolved in this recent PR - #78