这个坑我之前踩过！核心原因是Windows下的VSCode C#扩展和WSL里的dotnet工具对项目文件路径的处理逻辑不一致，执行dotnet build/dotnet test后，扩展找不到正确的依赖信息直接罢工了。试试下面几个实用的解决办法：

1. 避免命令自动修改项目文件路径 #

执行WSL终端里的dotnet命令时，加上--no-restore参数，比如：

dotnet build --no-restore
dotnet test --no-restore

这样可以阻止命令自动触发restore操作，避免生成Linux风格的路径写入项目文件，Windows下的VSCode就能保持对项目依赖的正确识别了。

如果已经执行过命令导致路径混乱，可以手动打开.csproj文件，检查<HintPath>等节点的路径，把Linux风格的/改成Windows的\；或者在WSL里执行一次dotnet restore后，回到VSCode按Ctrl+Shift+P选择Reload Window重新加载项目。

2. 让C#扩展直接使用WSL的dotnet环境 #

统一两边的环境是根治问题的办法：

1. 打开VSCode设置（快捷键Ctrl+,），搜索并添加以下配置：

"omnisharp.useWsl": true,
"omnisharp.path": "latest"

2. 重启VSCode，此时C#扩展会自动连接到WSL中的dotnet环境，不管你在终端执行什么命令，两边的路径处理逻辑一致，就不会再出现红波浪线和无限要求Restore的情况了。

3. 清除Omnisharp缓存重启服务 #

有时候缓存会搞出奇怪的问题：

• 按Ctrl+Shift+P打开命令面板，输入OmniSharp: Restart OmniSharp，先尝试重启服务；
• 如果没用，找到Windows下的Omnisharp缓存目录（一般是%USERPROFILE%\.omnisharp\cache），删除里面的所有内容，再重启VSCode重新加载项目。

4. 检查版本兼容性（可选） #

你当前用的VSCode 1.20.0和C#扩展1.14.0都比较老旧，虽然.NET Core 2.0本身已停止支持，但如果条件允许，尝试升级VSCode到兼容的较新版本（注意不要太新导致不支持.NET Core 2.0），或者匹配对应版本的C#扩展，也能减少这类兼容性问题。

内容的提问来源于stack exchange，提问作者mipnw