4

Very often, actually most of the times, Visual Studio2005 doesn't detect that some header included in some CPP file C++ project was changed. As the consequence, it doesn't recompile the project if only header is changed.

It doesn't depend on the "precompiled headers" settings. It doesn't happen in VS 2006 but in every version of VS 2005 and VS 2008 it does. It happens for all the projects, not for some specific one.

It doesn't happen if header file is a part of the project, i.e. if it appears in the vcproj file

The only way to resolve the issue is to perform a clean build.

Any advise is strongly appreciated.

Joel Coehoorn
  • 399,467
  • 113
  • 570
  • 794
Moisei
  • 1,162
  • 13
  • 30

4 Answers4

3

Most of the time (especially in C projects) this happens because of the "Enable minimal rebuild" project setting. In "minimal rebuild" mode VS2005 tries to make more precise decisions over what needs to be rebuild: not based on which header files were modified, but rather based on which individual class definitions were modified. In C projects (as opposed to C++ ones) this approach fails basically 100% of the time, i.e. it completely ignores modified header files and never rebuilds anything. Very annoying. I don't know what kind of project you are building, but maybe it might fail in C++ projects as well.

Anyway, try setting "Enable minimal rebuild" to "No". (This is a project setting, BTW, not a global VS setting). This should revert VS to the traditional file-based rebuild behavior.

AnT stands with Russia
  • 312,472
  • 42
  • 525
  • 765
2

First of all VS only checks those headers that are part of your project (included in the project file/part of the file tree).

There are some header files that are handled in a very special manner, like for example the resource.h. This file has a comment tag at its beginning that defines the file as non-dependant. See my other question about that issue here on SO.

VS also caches the class dependencies (which class is declared in what header, which cpp uses what header, etc.) if you use the minimal rebuild compiler option (/Gm if I remember correctly). See this MSDN page on /Gm compiler setting for more details like this:

Minimal rebuild relies on class definitions not changing between include files. Class definitions must be global for a project (there should be only one definition of a given class), because the dependency information in the .idb file is created for the entire project. If you have more than one definition for a class in your project, disable minimal rebuild.

Also, I am not sure if dependencies are correctly resolved if you use the force include project setting...

Hope that was of any use.

Community
  • 1
  • 1
fmuecke
  • 8,708
  • 1
  • 20
  • 25
  • "First of all VS only checks those headers that are part of your project (included in the project file/part of the file tree)" ----- this is not correct, sorry. VS observers all the header files, even if they are not part of the project but included in some cpp files. minimal rebuild is disabled. it must be something else. it is not resource header but plan header file. thanks – Moisei Nov 05 '09 at 23:02
  • Regarding Minimal Rebuild /Gm, I found [https://developercommunity.visualstudio.com/comments/189247/view.html](this post by Visual C++ Team member) enlightening: "....C++ MinimalRebuild using /Gm feature hasn't been actively developed on for years" – Tyson Hilmer Mar 22 '18 at 11:42
0

I just ran into this problem - turns out I copied a VS Project folder (very bad idea) and continued working on the copy of my project. But since all the include paths etc. still pointed to the original project (stupid VS for using absolute paths...), VS "didn't detect" the header changes, in other words, was looking at the wrong include location.

smoothware
  • 898
  • 7
  • 19
0

For those of us still having this issue with vs 2015, 2017 and 2019 (probably some more versions) and have tried turning off precompiled headers, creating a brand new solution/project (not copying anything over), disabling minimal rebuild and so on. And just want a solution that works and doesn't mean running clean or rebuild manually before every test run.

You can fix by brute force:

Go to project properties

"custom build step"

"execute before" and set to "Clean"

I wonder how many things I and others have unlearned by not knowing VS was actually just running the broken old version of the code without the changes that actually did fix the code?

user12897617
  • 1