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:

Answer 1

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

Answer 2

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 3

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

Answer 4

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 5

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 6

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