我不确定是否有其他人遇到过这种情况，但通常，当我打开这个特定的解决方案时，我会看到一个完整的错误列表（见下文）。
如果我双击其中一个，Visual Studio 似乎会被唤醒，并且与该特定 cs 文件相关的错误会消失。这不是一个关键问题，而且比其他任何事情都更令人恼火，但我想知道，我的代码是否有问题导致了这种误报，或者是随机的 Visual Studio 行为？
【问题讨论】：
标签： c# visual-studio-2015
我也有这个问题。 删除 bin 和 obj 文件夹不起作用。 清洁溶液不起作用。 各种平台我需要保持原样。
帮助我关闭解决方案并删除文件夹 .vs，该文件夹通常充满有问题的混乱。打开解决方案后，所有错误错误都消失了。
【讨论】：
.vs。文件夹，甚至没有删除 bin/obj、清理解决方案、重建或其他任何东西，当我重新打开 Visual Studio 时，它工作了，错误消失了！
正如评论中提到的，您可以进行清理和重建。如果这对您不起作用，您可以浏览到解决方案文件夹并在每个项目文件夹中删除 bin 和 obj 文件夹。然后执行构建。
您可能还想查看您的Configuration Manager 并确保您的所有项目都设置为相同的Configuration（调试/发布）和Platform（任何CPU/x86/等...）和标记为为该配置构建。
最后，您可能还想查看Build Order 以获得您的解决方案。确保所有项目都按正确的顺序构建。
-- 编辑：
我将在此处添加的 cmets 中提出的问题是确保解决方案中的任何库项目都添加为 Project References，而不是直接引用输出 DLL。
【讨论】：
using 语句有很多对该项目的引用。我假设我正在构建项目并使用输出 DLL 作为参考，但我可能是错的。在这里为我的无知道歉。
Projects 选项卡添加它，还是通过Browse 选项卡添加它并选择输出DLL文件？如果您确实直接引用 DLL 文件，我会更改它并通过Add References 窗口中的Projects 选项卡选择项目。这样可以确保每次进行更改时都会构建库项目。
只有在晚年才变得明显，并且仅在对这个老问题进行反思时才有意义的是，我们遇到此问题的特定解决方案包含一个网站项目，而不是一个 WebApplication 项目。当我们开始深入研究这些重复出现的错误并注意到它们只与代码隐藏文件相关并且都与当前上下文中不存在的 Control 名称有关时，这一点变得很明显。
在这两种项目类型之间的各种差异中，似乎缺少每个 ASP 页面的设计器文件可能是一个促成因素。一旦您双击它，错误就会消失，这可能表明 VS 在您打开相关页面/代码隐藏文件之前无法跟踪控件引用。
我们将迁移到 Web 应用程序作为临时措施。
希望这一见解对其他人有所帮助！
【讨论】：