Visual Studio: project is not up to date “because ”AlwaysCreate“ was specified”?

Question

I've migrated a solution from VS2008 to VS2010 (SP1).
Now one of my project never finds peace in being up-to-date. Every build have the following output:

1>------ Build started: Project: PROJ_NAME, Configuration: Release Win32 ------
1>Build started 19/05/2011 7:59:27 AM.
1>InitializeBuildStatus:
1>  Creating "Release\PROJ_NAME.unsuccessfulbuild" because "AlwaysCreate" was specified.
1>ClCompile:
1>  All outputs are up-to-date.
1>  All outputs are up-to-date.
1>Lib:
1>  All outputs are up-to-date.
1>  PROJ_NAME.vcxproj -> C:\projFolder.PROJ_NAME.lib
1>FinalizeBuildStatus:
1>  Deleting file "Release\PROJ_NAME.unsuccessfulbuild".
1>  Touching "Release\PROJ_NAME.lastbuildstate".
1>
1>Build succeeded.
1>
1>Time Elapsed 00:00:00.09
========== Build: 1 succeeded, 0 failed, 5 up-to-date, 0 skipped ==========

Any ideas?

Answer 1

I had a similar problem when one of the include files listed in the project didn't actually exist. I had deleted the file, but forgot to remove it from the project.

The dependency checker then believes the project is not up to date, but the builder finds nothing to build.

Answer 2

I had two projects that contained the same file. When the second project built, it compiled the file again, changing the 'touch' datetime. That in turn set the 'AlwaysCreate' flag for the first project.

I found this out by turning on 'CPS' in my "C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\devenv.exe.config" file, as in the xml snippet below. With that activated you can use the DebugView tool to get messages from VS2010 that state WHY it is rebuilding your project. Why those messages don't go into the build log is beyond me, but anyway there it is.

Add this:

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

To here:

<?xml version ="1.0"?>
<configuration>
    <configSections>
        <section name="msbuildToolsets" type="Microsoft.Build.BuildEngine.ToolsetConfigurationSection, Microsoft.Build.Engine, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
    </configSections>
    <system.diagnostics>
      <switches>
        <add name="CPS" value="4" />
      </switches>
    </system.diagnostics>
    <startup useLegacyV2RuntimeActivationPolicy="true">
        <supportedRuntime version="v4.0.30319" />

Answer 3

According to this thread on MSDN:

In my case in VS10 it was due to having missing (but non-complied .h files, thus no additional error to identify) in project folders.

A quick check that all project files can open in editor fixed this problem.

Answer 4

You must check also other files than .h. In my project Readme.txt was missed.

Answer 5

I moved a solution to a new folder, and every time I built a new version or tried to debug, it would want to claim that all the projects that made up the solution were out of date, even though it had just built them.

I searched all the .vcxproj files, used DebugView with CPS=4 (see @Bzzt's answer above) and discovered it was looking for the header files in their OLD location. Since the solution was moved, not copied, those files did not exist.

What finally solved it for me was cleaning the solution and doing one rebuild. After that the "AlwaysCreate" was no longer causing it the "build" all the sub projects. You have to clean each configuration (debug and release) separately, but once it has been rebuilt from the clean state, all is well.

In my case it didn't actually do any building, but MSBuild or whatever decided things were out of date, was using some cached filepath that no longer existed. The Clean and Rebuild replaced that cache and then it built like expected

Answer 6

I got the same issue.

Root-cause: incorrect build version of VS (32bit and 64bit)

Solution: Switch mode Debug/Release from 32 bit to 64 bit or reverse

http://postimg.org/image/3jurey1qr/

Answer 7

In Visual Studio 2010, I eliminated spurious rebuilds of a many-project solution by leaving Multiprocessor Compilation (/MP) unset (pity!). Previously, I had it enabled. Find the flag here: Common Properties > C/C++ > General > Multi-processor Compilation. Also, I noticed that I was able to eliminate individual projects' spurious rebuilds by rebuilding each project individually; then a build of each showed that each was up-to-date.

Answer 8

To get this to work, I simply renamed my existing output directory, in order to recreate all intermediate files (after trying all of the above accepted answers).

I've had success in the past using DebugView in VS2010 to find files to delete, but today that approach did not work. I could not find ANY reference to the missing header files, found using DebugView, within any of my code or project files XML. I also retrieved the outdated files from TFS to try with them both present and absent on my machine.

I then used GREP to search my entire solution directory, and the only results were in binary files: the old code files' *.obj, the project file's *.pdb, and vc100.idb. I don't know how these files get modified/replaced during build and rebuild, so I'm not sure if a previous reference in one of those files was responsible for claiming the old header files were missing.

Hope this helps someone down the road, and thanks for the above info that got me started!

Answer 9

For command line msbuild.exe builds you can use /verbosity:detailed and search the output for

• "will be compiled as" to find compilations
• "Source compilation required" to find links

Note: Output can be piped to file by using msbuild.exe /verbosity:detailed > output.txt

e.g.

code.cpp will be compiled as C:\path\to\header.h was modified at 18/02/2016 15:58:31.
Outputs for C:\path\to\code.cpp:

Answer 10

You may also find this happens after a windows update see this: Up to date projects compiled again because of TZRE.DLL date stamp is in the future after a windows update

The solution is to wait till that time, and the problem will magically vanish. I just had the same problem, My TZRES.DLL file is 17/07/2018 19:54, the time now is 17/07/2018 15:15