vscode调试c#必须使用coreclr调试器，type字段只能填coreclr；需确保omnisharp就绪、项目根目录正确打开、launch.json中program路径动态生成、远程调试时pipetransport自动拉取vsdbg并精确配置sourcefilemap。
VSCode调试C#必须用coreclr调试器，不是.net或csharp
VSCode里调试C#程序，launch.json中type字段只能填coreclr，填.net、csharp或clr都会报错“No debug adapter found”。这是由C# Dev Kit底层依赖的调试适配器决定的，和.NET版本无关——哪怕你装的是.NET 8，调试器类型仍是coreclr。
常见错误现象：
- F5后弹出“Could not find the debug adapter for 'xxx'”
- 状态栏显示
no project，但launch.json已存在 - 断点灰色不生效，鼠标悬停提示“Breakpoint ignored because no symbols have been loaded”
根本原因：VSCode没识别到C#项目上下文，导致coreclr调试器无法加载符号。此时type写对也没用，得先解决项目识别问题。
OmniSharp就绪是调试前提，不是可选项
调试前必须确认OmniSharp已完全加载，否则coreclr调试器连程序入口都找不到。OmniSharp: Ready出现在状态栏右下角，且输出面板（Ctrl+Shift+U）中OmniSharp Log有Workspace loaded或Project loaded日志，才算真正就绪。
容易踩的坑：
- 只打开
Program.cs单文件，没用File > Open Folder打开含.csproj或.sln的根目录 → OmniSharp根本不启动 - 装了C# Dev Kit但没重启VSCode → 状态栏无提示，命令面板搜不到
OmniSharp: Restart -
omnisharp.useModernNet设为false，但项目目标是net8.0→ 日志卡在Downloading...，重构和调试全失效 - Linux/macOS用户
$PATH没包含/usr/share/dotnet→dotnet --version在终端能运行，但在VSCode集成终端里报command not found
launch.json里program路径不能硬编码
program字段必须指向编译后的DLL，但绝不能写死路径如"./bin/Debug/net8.0/MyApp.dll"。它得用变量动态拼接，否则换项目、换框架、换配置（Debug/Release）就立刻失效。
正确写法示例：
"program": "${workspaceFolder}/bin/${config:dotnet.defaultConfiguration}/${config:dotnet.defaultTargetFramework}/${fileBasenameNoExtension}.dll"
更稳妥的做法是直接复用构建任务输出：
- 确保
tasks.json里args含"/property:GenerateFullPaths=true" - 在
launch.json中用"preLaunchTask": "build"触发构建 - 让
coreclr调试器自动从MSBuild输出读取OutputPath，而不是靠人猜路径
如果program为空或路径404，F5会静默失败，控制台不报错，只在调试控制台底部闪一下Failed to launch debug adapter。
远程调试别碰vsdbg手动下载，优先走pipeTransport自动拉取
远程附加调试时，pipeTransport配置里的debuggerPath不要指向本地已下载的vsdbg，而应留空或设为~/vsdbg/vsdbg，让VSCode在首次连接时自动通过SSH拉取匹配版本。手动下载容易错配架构（x64/arm64）或.NET版本（vsdbg-17.10不支持.NET 8.0.300）。
关键检查点：
-
pipeArgs中SSH参数必须含-T（禁用TTY），否则连接卡住 - 远程机器
~/vsdbg目录需有写权限，否则自动下载失败后不会重试 -
sourceFileMap映射必须精确到远程源码绝对路径，比如"/home/user/src/MyApp"不能简写成"/home/user/src"，否则断点无法命中
最常被忽略的一点：远程进程必须以dotnet run或dotnet exec方式启动，且未加--no-build；若直接运行已发布的MyApp.dll，PDB可能未随附，调试器加载符号失败。
