很多时候，实际上大多数情况下，Visual Studio2005都没有检测到某些CPP文件C ++项目中包含的某些标题被更改了。因此，如果仅更改标头，则不会重新编译项目。
它不依赖于“预编译头”设置。它不会发生在VS 2006中，但在每个版本的VS 2005和VS 2008中都会发生。它适用于所有项目，而不是某些特定项目。
如果头文件是项目的一部分，即它出现在vcproj文件中，则不会发生这种情况
解决问题的唯一方法是执行干净的构建。
任何建议都非常感谢。
大多数情况下（特别是在C项目中），这是因为“启用最小重建”项目设置。在“最小重建”模式下，VS2005尝试对需要重建的内容做出更精确的决策：不是基于哪些头文件被修改，而是基于修改了哪些单独的类定义。在C项目中（与C ++项目相反），这种方法基本上在100％的时间内失败，即它完全忽略修改的头文件而从不重建任何东西。很烦人。我不知道你正在构建什么样的项目，但也许它可能在C ++项目中失败。
无论如何，尝试将“启用最小重建”设置为“否”。 （这是项目设置，BTW，而不是全局VS设置）。这应该将VS恢复为传统的基于文件的重建行为。
首先，VS仅检查属于项目一部分的标头（包含在项目文件/文件树的一部分中）。
有一些头文件以非常特殊的方式处理，例如resource.h。此文件的开头有一个注释标记，用于将文件定义为非依赖项。在这里看看我的other question about that issue。
如果你使用最小重建编译器选项（/ Gm，如果我没记错的话），VS还会缓存类依赖项（哪个类在什么标题中声明，哪个cpp使用什么标题等）。有关详细信息，请参阅此MSDN page on /Gm compiler setting：
最小重建依赖于不在包含文件之间更改的类定义。类定义对于项目必须是全局的（应该只有给定类的一个定义），因为.idb文件中的依赖关系信息是为整个项目创建的。如果项目中的类有多个定义，请禁用最小重建。
此外，如果您使用强制包含项目设置，我不确定是否正确解析了依赖项...
希望有任何用处。
我刚遇到这个问题 - 结果我复制了一个VS Project文件夹（非常糟糕的主意）并继续处理我的项目副本。但由于所有包含路径等仍然指向原始项目（使用绝对路径的愚蠢VS ...），VS“没有检测到”标题更改，换句话说，正在查看错误的包含位置。