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

For me it was the presence of a non-existing header file on "Header Files" inside the project. After removing this entry (right-click > Exclude from Project) first time recompiled, then directly

========== Build: 0 succeeded, 0 failed, 5 up-to-date, 0 skipped ==========

and no attempt of rebuilding without modification was done. I think is a check-before-build implemented by VS2010 (not sure if documented, could be) which triggers the "AlwaysCreate" flag.

Answer 2

I had this problem and found this:

http://curlybrace.blogspot.com/2005/11/visual-c-project-continually-out-of.html

Visual C++ Project continually out-of-date (winwlm.h macwin32.h rpcerr.h macname1.h missing)

Problem:

In Visual C++ .Net 2003, one of my projects always claimed to be out of date, even though nothing had changed and no errors had been reported in the last build.

Opening the BuildLog.htm file for the corresponding project showed a list of PRJ0041 errors for these files, none of which appear on my system anywhere: winwlm.h macwin32.h rpcerr.h macname1.h

Each error looks something like this:

  MyApplication : warning PRJ0041 : Cannot find missing dependency 'macwin32.h' for file 'MyApplication.rc'.  

Your project may still build, but may continue to appear out of date until this file is found.

Solution:

Include afxres.h instead of resource.h inside the project's .rc file.

The project's .rc file contained "#include resource.h". Since the resource compiler does not honor preprocessor #ifdef blocks, it will tear through and try to find include files it should be ignoring. Windows.h contains many such blocks. Including afxres.h instead fixed the PRJ0041 warnings and eliminated the "Project is out-of-date" error dialog.

Answer 3

For Visual Studio/Express 2010 only. See other (easier) answers for VS2012, VS2013, etc

To find the missing file(s), use info from the article Enable C++ project system logging to enable debug logging in Visual Studio and let it just tell you what's causing the rebuild:

1. Open the devenv.exe.config file (found in %ProgramFiles%\Microsoft Visual Studio 10.0\Common7\IDE\ or in %ProgramFiles(x86)%\Microsoft Visual Studio 10.0\Common7\IDE\). For Express versions the config file is named V*Express.exe.config.

2. Add the following after the </configSections> line:

   <system.diagnostics>
     <switches>
       <add name="CPS" value="4" />
     </switches>
   </system.diagnostics>
   

3. Restart Visual Studio
4. Open up DbgView and make sure it's capturing debug output
5. Try to debug (hit F5 in Visual Studio)

6. Search the debug log for any lines of the form:

   devenv.exe Information: 0 : Project 'Bla\Bla\Dummy.vcxproj' not up to date because build input 'Bla\Bla\SomeFile.h' is missing.

   (I just hit Ctrl+F and searched for not up to date) These will be the references causing the project to be perpetually "out of date".

To correct this, either remove any references to the missing files from your project, or update the references to indicate their actual locations.

Note: If using 2012 or later then the snippet should be:

<system.diagnostics>
  <switches>
   <add name="CPS" value="Verbose" />
  </switches>
</system.diagnostics>

Answer 4

We also ran into this issue and found out how to resolve it.

The issue was as stated above "The file no longer exists on the disk."

This is not quite correct. The file does exist on the disk, but the .VCPROJ file is referencing the file somewhere else.

You can 'discover' this by going to the "include file view" and clicking on each include file in turn until you find the one that Visual Studio can not find. You then ADD that file (as an existing item) and delete the reference that can not be found and everything is OK.

A valid question is: How can Visual Studio even build if it does not know where the include files are?

We think the .vcproj file has some relative path to the offending file somewhere that it does not show in the Visual Studio GUI, and this accounts for why the project will actually build even though the tree-view of the includes is incorrect.

Answer 5

I had a similar problem, but in my case there were no files missing, there was an error in how the pdb output file was defined: I forgot the suffix .pdb (I found out with the debug logging trick).

To solve the problem I changed, in the vxproj file, the following line:

<ProgramDataBaseFileName>MyName</ProgramDataBaseFileName>

to

<ProgramDataBaseFileName>MyName.pdb</ProgramDataBaseFileName>

Answer 6

I met this problem today, however it was a bit different. I had a CUDA DLL project in my solution. Compiling in a clean solution was OK, but otherwise it failed and the compiler always treated the CUDA DLL project as not up to date.

I tried the solution from this post.

But there is no missing header file in my solution. Then I found out the reason in my case.

I have changed the project's Intermediate Directory before, although it didn't cause trouble. And now when I changed the CUDA DLL Project's Intermediate Directory back to $(Configuration)\, everything works right again.

I guess there is some minor problem between CUDA Build Customization and non-default Intermediate Directory.