‘AlwaysCreate’ forces project to be re-built


Have you lost time because Visual Studio always thought that a project was out-of-date? Recently had a customer who faced this issue. He migrated his project from VS2008 to VS2010. Rebuilt the whole project and tried to run. He saw this message box pop up…



If you click ‘Cancel’ and do a build, then in the output window you’ll see this…

1>------ Build started: Project: TestAlwaysCreateIssue, Configuration: Debug Win32 ------
1>Build started 3/12/2013 6:24:04 AM.
1> Creating "Debug\TestAlwaysCreateIssue.unsuccessfulbuild" because "AlwaysCreate" was specified.

This message is quite confusing and doesn’t give a hint as to what actually is wrong and why the project is being re-built! Visual Studio internally decides the project is out-of-date and hence decides to build again before execution.

You won’t lose time if the project is a small one but think about a solution having numerous projects a build/relink is going to take forever to complete (I’ve faced this personally for some reason this rebuild issue vanished after sometime).


So what causes this false rebuild?

To figure why Visual Studio decides that project is out-of-date you’ll have to enable project system logging in visual studio. See following blog on how to enable this feature in Visual Studio.

blogs.msdn.com/b/vsproject/archive/2009/07/21/enable-c-project-system-logging.aspx, for convenience I’ll paste in here relevant part from the blog…


To enable logging in the Visual C++ project system you just have to add a snippet to a .config file:

  1. Since it can be difficult to recover from a damaged devenv.exe.config file, consider copying the file to devenv.exe.config.original before modifying it so you have a backup copy you can revert to if things go awry.
  2. Open a text editor with admin privileges.
  3. Open your VisualStudioInstallFolder\Common7\IDE\devenv.exe.config file. Note this will be in %ProgramFiles(x86)% on 64-bit Windows.
  4. Add this snippet to your devenv.exe.config file just below the <configSections /> block:
    1. For Visual Studio 2012 and below...
      <switches><add name="CPS" value="4" /></switches>
      </system.diagnostics >
    2. For Visual Studio 2013<system.diagnostics>
      <switches><add name="CPS" value="Verbose" /></switches>
  5. Save the text file.


Above block of xml will enable diagnostic logging of build activities in Visual Studio. To view the diagnostic logs from Visual Studio you should either have a debugger hooked onto visual studio or you should have DebugView. DebugView is a tool that helps viewing application output which the application does via OutputDebugString API.

Output in DebugView should look like as follows once you enable project system logging in Visual Studio. Screenshot…


Now follow these steps…

  1. Start DebugView 
  2. Rebuild
  3. Build
  4. In DebugView window search for the string ‘missing’ or 'not up to date', better still to save the DebugView log entries and open it in notepad and then search.
  5. In this case we found the following message…
    [2968] Project 'C:\Projects\TestAlwaysCreateIssue\TestAlwaysCreateIssue\TestAlwaysCreateIssue.vcxproj' not up to date because build input 'C:\PROJECTS\TESTALWAYSCREATEISSUE\TESTALWAYSCREATEISSUE\NONEXISTENT.H' is missing.
  6. Copied above line of text from DebugView. The message clearly says why visual studio thinks the project is not up-to-date! The reason being nonexistent.h file is missing from disk.
  7. The file nonexistent.h file was deleted from disk on purpose to reproduce this issue.

Its quite easy to reproduce the issue, just add a .h file from disk to the project and then rename/delete this file, rebuild and build. You’ll see that Visual Studio says the project is not up-to-date. See below screenshot…



Resolution is quite easy, just remove the non-existent file from the project. 


Yes to get to the root cause we had to do some magic but that’s how it is for now. This behavior is there in VS2012 as well. So hope this saves some of your valuable time. If you know of a better or straight forward way to solve this do let us know. I’d like to thank Steve Horne (Sr. EE) at Microsoft who troubleshot a similar case long back, found all this information out of that case. Thanks Steve!

Please remember to undo the changes made to devenv.exe.config.