Why is Visual Studio 2008 always rebuilding my whole project?
Asked Answered
S

18

12

I have a Visual Studio project with about 60 C++ source files. I can do a build, and it completes without errors. But if I immediately hit F7 again, it always re-compiles about 50 of the source files. It doesn't re-compile all of the files, which is strange.

I have 'Enable minimal rebuild' (/Gm) set. Any ideas why it might be doing this? None of the files have a Modified Date in the future.

Spiroid answered 20/6, 2009 at 20:33 Comment(6)
Sorry. It's mostly C++, with some C.Spiroid
Does the problem go away if you do "Solution/Clean" and/or "Rebuild All"? Does it go away if you switch off the "Enable minimal rebuild" option?Kettledrum
I tried clean and rebuild all, but it still happens. Didn't try disabling minimal rebuild. However, this morning it seems to be behaving itself!Spiroid
FWIW there have been problems in the past with features like "Incremental Link"; so I switch those off and concentrate on other ways to reduce build times.Kettledrum
"Other ways" such as #1015132 and as described in Lakos' book.Kettledrum
my rebuilds were caused by header files that were part of the project but in fact did not exist, due to moving files around. overlooked the big question marksGurolinick
C
8

Are any of your file dates in the future? This can occur if you changed time zones or changed the system clock time. Dates in the future will confuse the IDE and force a rebuild every time F7 or F5 is hit.

Christlike answered 20/6, 2009 at 20:50 Comment(3)
None of the source files are in the future. I checked all of the files.Spiroid
This has always been the case when this has happened to me. Double-check your file dates, including headers from external sources!Libertarian
I've had this happen to me many times and this was never the case.Rasheedarasher
T
7

I've solved the same problem.

In my case compiler displayed warning, that /Zi option is required if /Gm is specified.

/Gm enables "minimum rebuild", which requires debug information in .pdb file. So, if you don't want to use .pdb, also disable minumum rebuild - it solved a problem in my case.

Toluol answered 18/1, 2012 at 16:46 Comment(0)
L
5

Most probably is a matter of dependencies.

Consider the following possibilities:

  • If you have custom build tools defined for some of the files in your solution, make sure that the output property contains the right file name(s). If the output of the build tool doesn't correspond to the one(s) specified in the output file names, the builder will rebuild that file.

  • If you have custom build events, check whether the output from those build events don't affect the dependencies of the files to be built.

  • I had problems when trying, at post-build, to copy or move some of the output files to a build folder. The post build operations that affect the timestamp of the ouput files of the build process will determine rebuild each time.

Leone answered 20/6, 2009 at 20:51 Comment(1)
I have no custom build events. Everything is just a normal compile and link, with libraries.Spiroid
S
4

In my case of such effect (C++ via VS2005) it was on Release configuration only, and the Studio tells in the build output, that compiler option /Gm is ignored if /Zi - option is not set. After setting /Zi via

Configuration Properties -> C/C++ -> General -> Debug Information Format : Program Database (/Zi) ,

it was ok. But isn`t there something wrong, when the Release Configuration needs something about Debugging? Not yet clear to me!

Skate answered 26/2, 2011 at 10:11 Comment(2)
This was my problem in the end, I must have accidentally turned off the debug info (/Zi) on my release project - apparently it is used during the build process to decide what needs building!Needful
It looks like you either need to have an empty string for the ProgramDatabase name, or you have to generate the database. Setting the build output to diagnostic level you can see this message: Task "Delete" skipped, due to false condition; ... ('ProgramDatabase' != '' and 'ProgramDatabase' != 'OldStyle' and 'ARM\Release\vc110.pdb' != '' and !Exists(ARM\Release\vc110.pdb)).Needful
U
4

Project Properties -> "C/C++" -> "Output Files" -> "Program Database File Name" option should not be empty. Set this option by selecting from drop-down box . The option will be set like this: $(IntDir)\vc90.pdb. And line ProgramDataBaseFileName="" will be removed from vcproj file.

Then only changed *.cpp files will be recompiled when you build the project or solution.

Urbana answered 2/3, 2012 at 14:34 Comment(0)
N
3

I'm having the same problem, and it seems to be because I've turned browse information off. Properties->C/C++->Browse Info->Enable Browse Info->None. The only fix I've found is turning it back on. This is for an xbox 360 project, fwiw, my other projects don't have the problem.

Nonchalance answered 16/7, 2009 at 0:27 Comment(0)
E
3

It seems that this problem can be caused by many things, but what fixed it for me was:

  1. Closing Visual Studio
  2. Manually deleting all bin and obj folders (Clean doesn't seem to do the trick)
  3. Opening the solution and running Clean (I'm not sure if this is necessary, but I did it just in case...)
  4. Building like normal

Note: This was for a C# program in Visual Studio 2010.

Excaudate answered 9/8, 2010 at 13:31 Comment(0)
I
3

After a couple days of googling, I ended up with a solution to my problem.

I encountered this problem when I moved my projects to a new PC. I had checked several times the creation date of the files. These dates were up-to-date, however the modification dates were in the bast (kinda bizarre) even when I changed the files.

A simple update of the files resolved the problem.

Invertase answered 9/5, 2011 at 13:21 Comment(0)
K
2

A reason is if the 'date last modified' for one of the source file is set for some date in the future: it rebuilds, and then the source file is still later than the executable.

This problem with the dates can happen if the source file is located in a directory a remote machine (a network share), and/or may even happen if your machine's time isn't synchronised with the date of the machine which is running the server of your source version control system.

Kettledrum answered 20/6, 2009 at 20:51 Comment(1)
None of the source files are in the future. All files are on my local machine.Spiroid
P
1

Check your project includes any .h header file that doesn't exist on disk. Always happens to me when I delete a header file I'm not actually including anywhere, but forget to delete it from my solution navigator in VS. Note: missing headers produce no errors during the build (when not #included anywhere).

Pacification answered 31/8, 2011 at 3:55 Comment(0)
B
1

Check your project's Program Database Filename setting. For some reason, if this is set to the name of a directory (such as "$(IntDir)\"), it can sometimes cause VS to rebuild your project every time, even if you're not generating PDB files (i.e. Debug Information Format is set to "Disabled").

This is a bug in VS2008; I have not yet reproduced it yet in VS2010, but my tests haven't been thorough, so I'm not confident saying that the behavior isn't present in VS2010.

Beam answered 21/10, 2011 at 15:55 Comment(0)
C
0

What caused similar symptoms at me was: I have several projects in a solution. There were .cpp files which were referenced (and therefore compiled) by >1 projects. Unfortunately Visual Studio creates .obj files with a very simple naming - it just replaces ".cpp" by ".obj". Creating wrapper .cpp-s with different named solved the problem.

Canaan answered 16/8, 2010 at 10:18 Comment(0)
C
0

I had something similar. Even though I did have pre and post build events, they weren't causing the issue. It turned out that I had a number of projects down the reference chain that had content files that were marked as "copy always" instead of "copy if newer" meaning that these projects were always considered "out of date". By changing all of these to "copy if newer", changes to my unit test project no longer forced a recompile of all of the other projects.

Choplogic answered 5/1, 2011 at 15:2 Comment(0)
B
0

Disabling "minimal rebuild" (Configuration Properties > C/C++ > Code Generation) fixed it for me. The compiler even left a clue:

1>cl : Command line warning D9007 : '/Gm' requires '/Zi or /ZI'; option ignored

Although I must point out, the compiler did not ignore the option as it said.

Bouldin answered 6/12, 2011 at 1:27 Comment(0)
G
0

In my case I changed system data time to previous date so it is rebuilding every time because of different time stamp of the files once changed to the current time its not rebuilding every time.

Gaillard answered 24/10, 2013 at 11:44 Comment(0)
N
0

We have that here regularly:

  • delete all intermediate and output files by hand. The clean option in vstudio is sometimes not enough. From a fresh start do the complete build. If after a complete build vstudio still wants to recompile certain files it might be related to next bullet.
  • if in your vcxproj a header file is referenced which is not on disk, the project is also recompiled. You might check this by some hidden feature described on MSDN blogs or just touch (i.e. click on it to open) all header files in the project exploder and see if one does not exist on disk
Normalie answered 5/11, 2013 at 19:12 Comment(0)
L
0

Had the same problem. Solved by: -delete output folder (obj,exe,all files) -run cygwin -cd project folder -run "touch *", which reset file modify date/time -build and enjoy problem fixed

Ladybird answered 2/9, 2014 at 6:59 Comment(0)
U
0

There is similar issue with project rebuild. Visual Studio does not recompile but re-links a project every time on F7 hit.

Fix is simple. Try to open in Editor all files included into project (from Solution Explorer double click on each file) and remove from solution those files which do not exist.

Urbana answered 13/6, 2017 at 14:2 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.