提问人:Cydrick Trudel 提问时间:7/17/2013 最后编辑:Cydrick Trudel 更新时间:7/11/2023 访问量:144901
Visual Studio 显示错误,即使项目生成也是如此
Visual Studio displaying errors even if projects build
问:
我在 C# 解决方案上使用 Visual Studio 时遇到问题。它显示完全随机的错误,但项目会构建。现在,我有 33 个文件有错误,我可以看到所有文件中的红色波浪线。
我尝试清理/重建解决方案,关闭Visual Studio,甚至重新启动计算机。我可以修改 .cs 文件,并看到解决方案中的更改。
有谁知道它为什么要这样做?
答:
也许你尝试重置智能感知缓存。我在 Visual Studio 2012 中遇到过类似的问题,当时在具有许多部分类定义的大型项目中工作。 减少部分部分解决了部分问题,也清除了智能感知缓存 - 一段时间。
评论
尝试将鼠标悬停在带下划线的元素上。它通常应该告诉您问题所在。要查看所有错误/警告的列表,请转到查看 => 错误列表。应在 IDE 底部打开一个表,其中列出了所有错误/警告。
评论
如果您有 ReSharper,请尝试清空 ReSharper 缓存:
在菜单中,ReSharper > Options > Environment > General > Clear Caches
以及禁用和重新启用 ReSharper:
在菜单中,ReSharper > > Options > General > Suspend / Restore
评论
清除 Resharper 的缓存对我而言没有帮助,尝试暂停/恢复,并使用 JetBrains 网站上的最新下载来修复 Resharper - 这些都没有帮助。这是在我尝试关闭/重新打开 VS 之后,重新启动我的机器,重复,构建/重建及其组合。
有趣的是,在 VS 第二次重启后暂停 Resharper 似乎解决了问题,但在我启用 Resharper <后又回来了——我尝试执行此序列 2-3 次以确保模式。
无论如何,当我找到这篇文章时,我仍然遇到问题:
所以我删除了隐藏的.SUO文件与解决方案在同一文件夹级别上,它神奇地解决了所有红色问题。
注意 - 对于 Visual Studio 2015,.SUO 文件位于 .vs/[solution_name]/v14 隐藏文件夹中。
评论
我遇到了这样的问题,Intellisense 似乎无法识别一个项目的存在(许多“找不到此类型”、“此命名空间不存在”等错误)。
在所有引用项目中删除并重新添加项目引用将解决此问题,但可以通过编辑问题项目的 .proj 文件来解决根本原因。
在“缺失”项目的 .csproj 文件的顶部附近是一个元素:
<ProjectGuid>{GUID}</ProjectGuid>
在所有引用项目中,.csproj 文件都是项目引用:
<ProjectReference Include="..\OffendingProject\OffendingProject.csproj">
<Project>{ANOTHER-GUID}</Project>
<Name>Offending Project</Name>
</ProjectReference>
引用的 GUID 与项目的 GUID 不匹配。将上述内容替换为已修复的问题,而无需遍历每个引用项目。{GUID}
{ANOTHER-GUID}
评论
我清理了解决方案,关闭了 VS,重新打开了它,构建了解决方案,并清理了未解析的红色线条并构建成功。
评论
有时,我必须通过浏览所有项目并手动删除“bin”和“obj”文件夹来执行自定义清理。若要在 Visual Studio 中查看它们,必须为每个项目启用隐藏文件和文件夹。完成此操作后,重新生成解决方案。
有时,如果您只是清理解决方案,错误就会消失,但它们最终可能会在一段时间后或下一次构建时再次出现。
顶级域名;卸载并重新加载有问题的项目。
当这种情况发生在我身上时,我(曾经)尝试关闭 VS 并重新打开它。这可能在大约一半的时间里起作用。当它不起作用时,我会关闭解决方案,删除 .suo 文件(或整个 .vs 文件夹),然后重新打开解决方案。到目前为止,这一直对我有用(在过去 10 个月内超过 6 次),但它有点乏味,因为有些事情会重置,例如您的构建模式、启动项目等。
由于通常只有一个项目有问题,我只是尝试卸载该项目并重新加载它,这奏效了。我的样本量只有 1,但它比其他两个选项快得多,所以也许值得尝试。(更新:我的一些同事现在也尝试过这个,到目前为止,它每次都有效。我怀疑这有效,因为它写入了 .suo 文件,并且可能修复了导致问题开始的损坏部分。
注意:这似乎适用于 VS 2022、2019、2017 和 2015。
评论
我通过删除Microsoft .NET框架的临时文件解决了这个问题。 位置: C:\Windows\Microsoft.NET\Framework64\v4.0.30319\临时 ASP.NET 文件 和 C:\Windows\Microsoft.NET\Framework\v4.0.30319\临时 ASP.NET 文件
REM DELETE ALL VS HIDDEN SOLUTION OPTION FILES
DEL /A:H /S *.SUO
对于我的具体情况,它是一个服务引用,另一个开发人员合并到主分支中。这完全没问题,除了语法突出显示无法解析生成的服务类,并且源都是红色下划线。清洁、重建、重新启动都无济于事。
我所要做的就是刷新服务引用,VS 设法在幕后将各个部分组合在一起。源代码或生成的文件没有变化。
在恢复将文件添加回我的项目的 git 提交后,我刚刚遇到了这个问题。
清理和重建项目不起作用,即使我在每一步之间关闭了 VS。
最终奏效的是将文件重命名为其他名称,然后再次更改。:脸掌:
遇到此问题,Visual Studio 无法识别单个类型,即使解决方案成功构建,该类型也显示红色波浪线。我注意到在解决方案资源管理器中,文件左侧没有展开箭头,该箭头显示扩展时的类和属性。
解决方法是从项目中排除文件并保存/生成,这会产生预期的错误,然后将文件包含在项目中并保存和生成。
执行这些步骤后,Visual Studio 再次开始识别我的类型。查看 git 中的差异,问题似乎是由于我的 .csproj 文件的行上的行尾不匹配。<Compile Include="..." />
0 - 右键单击解决方案并清理解决方案
1 - 关闭 VS
2 - 删除项目的 .suo 文件
3 - 开放 VS
4 - 生成解决方案
我发现在 Visual Studio 2017 中使用 Git 时经常发生这种情况,切换有依赖代码更改的分支。即使项目将成功生成,错误列表中仍会保留错误。
这些错误通常是命名空间问题和缺少引用,即使库引用存在也是如此。
解决方法:
- 关闭 Visual Studio
- 删除 {sln-root}.vs\SlnName\v15.suo 文件(隐藏)
- 重新启动 Visual Studio
评论
就我而言,VS 从未在项目属性>引用中保留导入的命名空间
当我尝试再次添加/检查它们时,我无法并且 vs 抛出错误,并且在保存项目 vs 时崩溃。当我重新打开所有标准导入的命名空间(system.data 等)时,它再次勾选了所有内容,然后它识别了所有内容,没有错误
在尝试了列出的所有选项后,我发现了发生这种情况的另一个原因。如果有人以 zip 格式向您发送源代码,或者您下载了 zip,则 Windows 可能已阻止所有文件。2 种解决此问题的方法:
方法1:
右键单击原始Zip文件 -> 选中“解锁” -> 单击应用
方法2:
如果这不是一个选项,则无需打开解决方案文件夹中每个文件的属性,只需打开 Power shell 并使用以下命令递归取消阻止:
Get-ChildItem -Path 'C:\<ROOT FOLDER OF SOLUTION>\' -Recurse | Unblock-File
对于 VS-2017,删除 .vs 文件夹对我有用。
我已经尝试了所有 6 个选项,但没有一个对我有用。以下解决方案解决了我的问题。
关闭 VS。 删除解决方案文件旁边隐藏的“.vs”文件夹。 重新启动 VS 并加载解决方案。
评论
- 首先关闭解决方案。
- 然后解决方案缓存文件删除(位于位置 C:\Users\Documents\Visual Studio\Backup Files/项目缓存文件)
- 然后删除 .suo 文件
- 然后打开解决方案并生成。
我希望能解决你的问题
以下解决方案对我有用
1 - 关闭 VS
2 - 删除 .vs 文件夹
3 - 开放 VS
4 - 生成解决方案
TL;DR:执行 Visual Studio 的全新重新安装
浪费了几个小时后,我仍然无法为 Visual Studio 2017 修复它。然后,我安装了 Visual Studio 2019 预览版,突然间,IntelliSense 再次向我显示 STL 类的成员(Visual Studio 2017 没有)。
因此,我的猜测是 Visual Studio 本身也可能存在问题(可能是缓存目录中的某些内容,或者通常是 PC 上与特定解决方案没有直接关系的内容),这可以通过干净和完整的重新安装来解决Visual Studio。我知道,这是一个愚蠢的“解决方案”,但就我而言,只有新的 Visual Studio (2019) 安装才有效。
如前所述,就我而言,只有 STL 类受到影响。IntelliSense 不会显示其成员,这很奇怪。我想,这可能与预编译的标头有关。我在某处读到STL和项目应该在同一驱动器上,将它们放在同一个驱动器上应该可以解决问题。但这些途径都没有取得成功。
以下是热门答案的集合。如果答案的 OP 对您有帮助,请为它投赞成票:
选项 1:清理、生成和刷新(@Mike Fuchs 选项)
正如 @Mike Fuchs 所提到的,请尝试以下操作:
在菜单中,构建>清洁解决方案
和
在菜单中,生成>生成解决方案
并选择有问题的项目,然后单击“刷新”按钮:
选项 2:清理、关闭、重新启动和生成(@Pixel选项)
如@Pixel所述,请尝试以下操作顺序:
- 清洁溶液
- 关闭 Visual Studio
- 打开 Visual Studio
- 构建解决方案
选项 3:清除 ReSharper 缓存(@GammaOmega选项)
如果您有 ReSharper,请尝试清空 ReSharper 缓存:
在菜单中,ReSharper > Options > Environment > General > Clear Caches
以及禁用和重新启用 ReSharper:
在菜单中,ReSharper > > Options > General > Suspend / Restore
选项 4:删除 .suo 文件(@Neolisk选项)
@Neolisk如前所述,删除 .suo 文件可能会解决您的问题。对于 Visual Studio 2015,该文件位于:
[解决方案路径]/.vs/[解决方案名称]/v14/.suo
对于 Visual Studio 2017:
[解决方案路径]/.vs/[解决方案名称]/v15/.suo
请注意,.vs 目录是隐藏的。
选项 5:卸载和重新加载项目(@TTT选项)
如前所述@TTT,尝试卸载导致问题的项目:
在“解决方案资源管理器”中,右键单击项目“卸载项目”。
并重新加载它
在“解决方案资源管理器”中,右键单击“项目”和“重新加载项目”。
选项 6:删除并添加 Microsoft.CSharp 引用(@Guilherme选项)
如前所述@Guilherme,尝试从有问题的项目中删除并添加对“Microsoft.CSharp”的引用。
在“解决方案资源管理器”中,展开项目,展开“引用”,右键单击“Microsoft.CSharp”并删除。
然后,右键单击“引用”>“添加引用”,从列表中选择“Microsoft.CSharp”,然后单击“确定”
评论
我的一位同事今天遇到了这个问题。我们在这里尝试了许多建议,除了下面描述的解决方案外,没有一个有效。
问题:
项目生成良好,但 Intellisense 无法识别某些类型,并将特定语句标记为无效。using
溶液:
将“解决方案平台”(在 VS 2017 中,这是“解决方案配置”下拉列表旁边的下拉列表,具有 x86、x64、AnyCPU、混合平台等值)更改为 AnyCPU。
项目的平台可能会有所不同,但似乎某些引用可能并非对所有平台都有效。
在工作中遇到了这个问题(运行 VS2017)。在这里尝试了所有答案。没有喜悦。
该项目可以很好地构建,但抱怨找不到命名空间/类型。到处都是红色的波浪线。“错误列表”窗口中出现大量错误。
我的解决方案包含 3 个项目。
发现其中一个项目的 NuGet 库引用中有 3 个不行。 合并了引用的库版本和 Bingo。
希望这对某人有所帮助。
布雷特。
卸载并重新加载项目解决了这个问题。
我发现,如果引用的项目针对的框架版本高于尝试使用它的项目,则可能会发生这种情况。您可以通过转到输出窗口并查找与此类似的内容来判断这是否是问题所在:
无法解析主引用“my_reference”,因为它 是针对“.NETFramework,Version=v4.7.2“框架。这 是比当前目标框架更高的版本 ".NETFramework,Version=v4.7”。
解决方案是更改一个或另一个项目的目标框架。
我注意到,有时在切换 git 分支时,Visual Studio (2017) 将无法识别在第二个分支中添加的某些文件中的类型。删除 .vs 文件夹可以解决此问题,但也会删除所有工作区设置。这个技巧似乎对我很好用:
- 解决方案资源管理器 -> 查找包含无法识别的类的文件。
- 单击“解决方案资源管理器”顶部的“显示所有文件”。
- 右键单击文件 -> 从项目中排除。
- 再次右键单击该文件 -> Include in project。
这会导致 Intellisense 分析它在切换分支时丢失的文件。
删除隐藏文件路径 = 您的解决方案\ .vs\ 您的解决方案名称 \v15\ .suo
评论
CheckForErrors
CheckForErrors
删除文件夹解决了我的问题。.vs
但它也重置了我的解决方案在 VS 中的当前设置。例如,当我重新启动 VS 时,我在解决方案中卸载的项目被重新加载,所有固定和打开的文档也被关闭。
我在 VS2019 中的症状是我会在构建时出现一些错误。然后,我将修复错误,并且构建将起作用,如“输出”窗口中所示。但是“错误”窗口仍然显示旧错误。我可以运行它就好了。关闭 VS2019 并重新操作解决了这个问题,但只是一小段时间。这在版本 16.4.3 上开始发生
这个解决方案似乎对我有用:
取消选中“工具”->选项->“项目和解决方案”-“>常规”->“允许并行项目初始化”
我发现这个修复程序隐藏在这里的评论中:https://developercommunity.visualstudio.com/content/problem/483450/vs-2019-intellisense-reports-compile-errors-when-r.html
删除SUO /隐藏的解决方案文件有很多答案。
就我而言,这是因为我需要以管理员身份运行 Visual Studio 才能发布。这会使用管理员权限覆盖这些文件。现在,当以标准用户身份运行时,我无法摆脱任何错误。
如果我在管理员模式下重新运行,我能够解决所有错误。
很多事情都可能导致它,正如这里的一长串答案所证明的那样。这是为我修复它的方法,我先尝试了几乎所有其他方法。
在 DEBUG 模式下生成解决方案。然后在 RELEASE 模式下构建它(当它有红色波浪线时,它不应该构建,但就我而言,它只是应该有绿色波浪线的警告,但它陷入了混乱并给了它们红色波浪线,即使在发布模式下,它仍然构建)。然后在 DEBUG 模式下构建。吐在手上,转身三次可选。
为我工作,而没有其他工作。
评论
一年多来,我一直在为这个问题而苦苦挣扎,但这些解决方案都没有帮助我:
- 删除 .suo
- 删除 .vs 文件夹
- 删除任何或所有缓存/临时文件夹
- 删除 obj / bin 文件夹
- 卸载/重新加载项目
我终于解决了这个问题 - 我在记事本中打开了 vbproj/csproj 文件,并注意到在 ItemGroup 部分中,有一个对我的主项目 dll 的引用。我删除了这个引用,重新打开了我的解决方案,问题得到了解决。
就我而言,当我在将 sdk 更新到最新版本后第一次尝试使用用 C# 9.0 编写的项目时,无论我做什么,它都会显示红线(它会构建得很好)。我在这里尝试了一切,但没有任何效果。 最后,我意识到问题出在我的旧版本的 Resharper 语法荧光笔上。 一旦我更新了 Resharper,所有的红色都消失了。
我遇到 IntelliSense 显示不存在的分散注意力的错误,但仍能够在 Visual Studio 2019 中生成和调试项目。Visual Studio 2017 中未出现此问题。最重要的是,我们无法导航到 Visual Studio 中的各种引用。
在尝试了发布的所有选项并找到这篇关于导航符号的帖子后: https://stackoverflow.com/a/49100341/999011
我们情况的解决方案与项目文件中的 & 引用有关,这些引用在上面的帖子中提到过。Microsoft.Net.Compilers
Microsoft.CodeDom.Providers.DotNetCompilerPlatform
但是,我从未更新过它们,我只是发现项目文件中有多个对不同版本的引用。在清理了这些内容并且每个包只有一个引用之后,分散注意力的红色波浪线消失了,导航符号开始工作。Microsoft.Net.Compilers
Microsoft.CodeDom.Providers.DotNetCompilerPlatform
我只能推测额外的引用是在升级期间添加的,因为我认为这个项目最初是在 Visual Studio 2015 中创建的。
就我而言,帮助了以下几件事:
- 删除以前从项目中排除的所有不需要的旧文件
- 关闭 VS
- 删除所有文件夹内容
bin
- 删除文件夹
.vs
- 清理/重建
- 在那之后,我仍然有一些虚假错误,但是数量明显较低(从 200 到大约 8),并且错误仅涉及资源字典路径,例如 当我尝试将路径更改为错误的路径时,重新构建然后纠正它并再次重建,然后最终清除了所有错误。如果相关的话,它是专门的 WPF 项目。
Generic.xaml
<ResourceDicitonary Source="example/path/somefile.xaml">
解决此类奇怪的项目配置错误的最佳方法是打开项目文件(右键单击项目,选择“编辑项目文件”),然后查看项目组,看看这些列表中的顺序和文件是否符合您的预期。
例如。
<ItemGroup>
<Compile Remove="out\of\date\path\to\foo\foo.cs" />
等。
有时(尤其是在移动文件时),项目文件可能会过期,并且其中仍有旧的无效条目,并且通过查看解决方案窗格设置,您永远不会知道它。
评论