Visual Studio 2010 always thinks project is out of

Question

I have a very similar problem as described here.

I also upgraded a mixed solution of C++/CLI and C# projects from Visual Studio 2008 to Visual Studio 2010. And now in Visual Studio 2010 one C++/CLI project always runs out of date.

Even if it has been compiled and linked just before and F5 is hit, the messagebox "The project is out of date. Would you like to build it?" appears. This is very annoying because the DLL file is very low-tiered and forces almost all projects of the solution to rebuild.

My pdb settings are set to the default value (suggested solution of this problem).

Is it possible the get the reason why Visual Studio 2010 forces a rebuild or thinks a project is up to date?

Any other ideas why Visual Studio 2010 behaves like that?

Answer 1

Another simple solution referenced by Visual Studio Forum.

Changing configuration: menu Tools → Options → Projects and Solutions → VC++ Project Settings → Solution Explorer Mode to Show all files.

Then you can see all files in Solution Explorer.

Find the files marked by the yellow icon and remove them from the project.

It's OK.

Answer 2

I spent many hours spent tearing out my hair over this. The build output wasn't consistent; different projects would be "not up to date" for different reasons from one build to the next consecutive build. I eventually found that the culprit was DropBox (3.0.4). I junction my source folder from ...\DropBox into my projects folder (not sure if this is the reason), but DropBox somehow "touches" files during a build. Paused syncing and everything is consistently up-to-date.

Answer 3

Another one on Visual Studio 2015 SP3, but I have encountered a similar issue on Visual Studio 2013 a few years back.

My issue was that somehow a wrong cpp file was used for precompiled headers (so I had two cpp files that created the precompiled headers). Now why did Visual Studio change the flags on the wrong cpp to 'create precompiled headers' without my request I have no clue, but it did happen... maybe some plugin or something???

Anyway, the wrong cpp file includes the version.h file which is changed on every build. So Visual Studio rebuilds all headers and because of that the whole project.

Well, now it's back to normal behavior.

Answer 4

In my case one of the projects contains multiple IDL files. The MIDL compiler generates a DLL data file called 'dlldata.c' for each of them, regardless of the IDL file name. This caused Visual Studio to compile the IDL files on every build, even without changes to any of the IDL files.

The workaround is to configure a unique output file for each IDL file (the MIDL compiler always generates such a file, even if the /dlldata switch is omitted):

• Right-click the IDL file
• Select Properties - MIDL - Output
• Enter a unique file name for the DllData File property

Answer 5

This happened to me multiple times and then went away, before I could figure out why. In my case it was:

Wrong system time in the dual boot setup!

Turns out, my dual boot with Ubuntu was the root cause!! I've been too lazy to fix up Ubuntu to stop messing with my hardware clock. When I log into Ubuntu, the time jumps 5 hours forward.

Out of bad luck, I built the project once, with the wrong system time, then corrected the time. As a result, all the build files had wrong timestamps, and VS would think they are all out of date and would rebuild the project.

Answer 6

Most build systems use data time stamps to determine when rebuilds should happen - the date/time stamp of any output files is checked against the last modified time of the dependencies - if any of the dependencies are fresher, then the target is rebuilt.

This can cause problems if any of the dependencies somehow get an invalid data time stamp as it's difficult for the time stamp of any build output to ever exceed the timestamp of a file supposedly created in the future :P