code_goto_definition / code_find_usages return SYMBOL_NOT_FOUND for VB.NET files (Roslyn navigation is C#-specific)

[tleclaire]

Summary

code_goto_definition and code_find_usages fail with SYMBOL_NOT_FOUND on VB.NET source files, even when the VB project is successfully loaded into the Roslyn workspace. Symbol navigation appears to be C#-specific.

The debugging side (ICorDebug) works perfectly for VB.NET — breakpoints in .vb files, stepping, evaluate, and variables_get all work, since it operates on IL + PDB sequence points. Only the Roslyn-based code navigation tools fail.

Environment

• debug-mcp 0.20.0 (via dnx -y debug-mcp)
• Windows 11 x64, .NET SDK 10.0.400
• Server started via stdio, called through an MCP proxy (tool passthrough verified 1:1)

Reproduction

Minimal VB console app:

Module Program
    Sub Main()
        Dim name As String = "vb-debug"
        Dim answer As Integer = 42
        Console.WriteLine($"Hello {name}, answer={answer}")
    End Sub
End Module

dotnet build -c Debug
dotnet new sln -n VbSmokeClassic --format sln
dotnet sln VbSmokeClassic.sln add VbSmokeTest.vbproj

Then via MCP:

1. code_load("VbSmokeClassic.sln")
   ✅ Success — project VbSmokeTest loaded, documents_count: 3, diagnostics: []
2. code_get_diagnostics(projectName: "VbSmokeTest")
   ✅ Success — total_count: 0 (workspace fully functional for the VB project)
3. code_goto_definition(file: ".../Program.vb", line: 5, column: 9) (exactly on the C of Console)
   ❌ SYMBOL_NOT_FOUND — No symbol found at ...Program.vb:5:9
4. code_find_usages(name: "VbSmoke.Program.Main")
   ❌ SYMBOL_NOT_FOUND — Symbol not found: VbSmoke.Program.Main

The identical flow on a C# console app (breakpoint, evaluate, goto_definition) works in the same session — this rules out the proxy, launch method, and PDB handling.

Expected behavior

VB source files should resolve symbols through the Roslyn VB syntax trees (Microsoft.CodeAnalysis.VisualBasic), so code_goto_definition, code_find_usages, and code_find_assignments work for VB projects loaded via .sln.

Suspected cause

The symbol-location logic in the code-analysis tools appears to walk C#-specific syntax trees (e.g. CSharpSyntaxNode casts or a C#-only parse), so VB syntax trees never yield a symbol at the given position — despite the workspace itself loading VB projects cleanly (step 1/2 above succeed, including diagnostics).

Related observation (separate, minor)

code_load path validation only accepts .sln/.csproj — a direct .vbproj or a .slnx solution is rejected with INVALID_PATH. VB solutions therefore must be loaded through a classic .sln. Worth relaxing the validation to .vbproj/.slnx alongside the VB navigation fix.

Workaround used

For VB codebases we fall back to external code search (knowledge-graph/grep) for symbol navigation and use debug-mcp purely for the (excellent) debugging capabilities.

---

Happy to provide the full test project if helpful. Thanks for the great tool — the ICorDebug approach works flawlessly on Windows.