vscode不能直接运行单个.cs文件，必须基于含.csproj的完整项目结构；因omnisharp仅识别标准项目上下文，单独打开.cs文件会导致“缺少必需的资产”等错误，正确做法是用dotnet new创建项目后以文件夹方式打开。
VSCode 能直接运行 C# 代码，但必须基于完整项目结构（含 .csproj 文件），不能像 Python 那样单文件 dotnet run Program.cs 启动——这是最常卡住新手的第一步。
为什么新建 .cs 文件后按 F5 会报错“缺少必需的资产”
VSCode 的 C# 支持依赖 OmniSharp 加载项目上下文，而 OmniSharp 只识别标准项目结构：.csproj 文件 + 正确的 TargetFramework 声明。单独打开一个 Program.cs，没有项目文件，OmniSharp 就无法解析命名空间、引用或 SDK 版本，自然报错。
- 错误典型提示：
Missing required assets to build and debug或Cannot resolve symbol 'Console' - 正确做法：必须用
dotnet new console -n MyApp创建项目，再用code .打开整个文件夹 - 验证是否就绪：状态栏右下角显示
OmniSharp: Ready，且Program.cs中Console.WriteLine无波浪线
dotnet run 和 F5 调试的区别与选用场景
dotnet run 是命令行编译+执行，适合快速验证逻辑；F5 是调试模式，支持断点、变量监视、调用堆栈——两者底层都依赖 bin/Debug/ 下的输出，但触发路径和配置来源不同。
-
dotnet run：在集成终端中执行，自动调用dotnet build→dotnet exec，无需launch.json - F5：读取
.vscode/launch.json中的program字段（默认指向bin/Debug/net8.0/MyApp.dll），首次按 F5 时 VSCode 会引导你选“.NET Core”环境并生成该文件 - 常见陷阱：手动改过
.csproj的TargetFramework（如从net8.0改成net6.0），但launch.json里路径没同步更新，导致 F5 找不到 DLL
OmniSharp 启动失败或卡在 “Loading…” 的真实原因
不是插件没装好，而是 SDK 路径未被正确识别或版本不匹配。OmniSharp 默认尝试用内置 Mono 运行，但在 macOS Sequoia 或较新 .NET SDK（如 8.0.302）下容易 fallback 失败。
- 先确认 SDK 是否可用：
dotnet --list-sdks应输出至少一行，如8.0.302 [/usr/local/share/dotnet/sdk] - 强制指定 SDK 路径：在
settings.json中添加"omnisharp.dotnetPath": "/usr/local/share/dotnet"（macOS/Linux）或"C:\Program Files\dotnet"（Windows） - 禁用 Mono 模式：
"omnisharp.useGlobalMono": "never"，避免旧版 Mono 干扰 - 重启 OmniSharp：命令面板输入
OmniSharp: Restart OmniSharp，比重启 VSCode 更快生效
调试时断点不命中？先检查这三件事
断点灰色空心圆、悬停显示 “未绑定”，往往不是代码问题，而是调试器没加载符号或项目未构建成功。
- 看终端输出：F5 启动时，集成终端应出现类似
Building project...→Starting debugger...，若卡在第一句，说明dotnet build失败（比如Program.cs有语法错误） - 确认
bin/Debug/下存在.dll和同名.pdb文件（调试符号），缺失.pdb会导致断点无效 - 检查
launch.json的type字段是否为"coreclr"（.NET 5+ 必须），而非过时的"mono"
真正的难点不在安装步骤，而在于理解 VSCode 不是 IDE 是编辑器——它所有智能功能都靠外部进程（OmniSharp、dotnet CLI）协作完成。一旦某个环节路径错、版本乱、权限缺，整条链就断。保持 dotnet --version、which dotnet、OmniSharp: Ready 三者一致，比反复重装插件管用得多。
