关键字仍然可以识别,但只能识别新的用户定义的类,使用命名空间也无法识别,代码运行良好,但这样的代码确实很烦人。
尝试了几个小时的所有方法,甚至到了运行 Windows 10 VM 的程度,新用户全新安装了 VS Code(仅使用用于扩展作者扩展的 C# 和 .NET 安装工具)和 .NET 7.0 SDK,但仍然有效不工作。
我正在考虑在我的主系统上重新安装 Windows,但发现它在虚拟机上不起作用,这也是毫无意义的,其他人也有这个问题吗?
这些问题是由 Visual Studio Code C# 扩展的
v2.x.x
引起的,该扩展不具有与当前 v1.x.x
(= OmniSharp 或 )相同的功能集(包括一些前所未有的功能,但也缺少一些功能) O#)版本。然而,未来的目标是让 v2.x.x
支持 v1.x.x
已经支持的内容。
您有四个选择之一:
v2.0.320
并添加包含您的项目的解决方案文件(请参阅更新 2023-08-05 部分)v1.x.x
)(请参阅原始答案部分)dotnet.server.useOmnisharp
设置为 true,返回 OmniSharp。接下来,卸载或禁用 C# Dev Kit。最后,重新启动 VS Code 才能生效。(引用自 Github - dotnet/vscode-csharp - 如何使用 OmniSharp)
v2.x.x
版本中出现功能对等(请参阅更新 2023-08-09 部分中链接的 Github 问题)正如 starball 和线程 在 v2.0.320 版本中 VS Code 的 IntelliSense 的 C# 扩展发生了什么变化? 在 SO 上,一般问题是版本 >=
v2.0.320
Microsoft 已决定切换到新的 Roslyn 语言服务器,而不是使用之前版本一直使用的 OmniSharp(也通常称为 O#)(请参阅 Github 版本 - 变更日志 v2.0.320)。微软确实为此受到了一些热捧(参见Visual Studio Magazine),因为这将引入闭源功能。
到目前为止,新的
v2
缺少 OmniSharp 版本提供的一些功能。然而,查看已知问题列表,我们计划将来在两个版本之间实现功能对等。
这里是截至 2023-08-09 的已知问题,基于 Github - dotnet/vscode-csharp - v2.0.320 中的已知问题:
请注意问题 #5722 - [O# Parity] 支持在没有解决方案的情况下加载项目/文件解决了此处面临的问题。
话虽这么说,你有我之前的答案中概述的可能性:
v2.0.320
并添加包含您的项目的解决方案文件(请参阅更新 2023-08-05 部分)v1.x.x
)(请参阅原始答案部分)dotnet.server.useOmnisharp
设置为 true,返回 OmniSharp。接下来,卸载或禁用 C# Dev Kit。最后,重新启动 VS Code 才能生效。(引用自 Github - dotnet/vscode-csharp - 如何使用 OmniSharp)
似乎只有当您的项目未在解决方案文件中列出时才会出现此问题,因此您可以创建一个解决方案文件,例如使用
dotnet new sln --name <solution name>
,然后使用 dotnet sln add <project path>
将项目添加到该解决方案。
当我将所有项目添加到解决方案文件中时,它正在使用新版本
v2.0.328
(今天发布,2023 年 8 月 5 日)。
我今天遇到了同样的问题(2023-08-04)。这是由于
v2.0.320
扩展的更新。您可以通过恢复到版本 v1.26.0
来修复此问题。
您可以通过转到
Extensions -> C# -> Install Another Version
恢复使用 UI:
还有一个与此相关的开放 Github 问题。
在 macOS 上,向项目添加解决方案文件对我来说不起作用。不过,在 Ubuntu Linux 上运行良好。仍然得到“无法找到 .NET Core 项目”的废话。最新的 SDK v6.0.414 运行时 6.0.22。 Rant:我只是没有时间做这个。不想恢复。