40

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?

Martin Ba
  • 37,187
  • 33
  • 183
  • 337
Hertzel Guinness
  • 5,912
  • 3
  • 38
  • 43
  • possible duplicate of [Visual studio 2010 build problems](http://stackoverflow.com/questions/4185638/visual-studio-2010-build-problems) – Alok Save May 19 '11 at 05:21
  • Try copying your entire project to a different location, also make sure to delete all the references to files (like .h files) that do not exist and let us know of the result. Check out this page too: http://connect.microsoft.com/VisualStudio/feedback/details/574245/alwayscreate-needs-documentation-or-vs10-fix – Alireza Maddah May 19 '11 at 05:24
  • @als similar output, not problem. However, indeed a duplication of http://stackoverflow.com/questions/2762930/vs2010-always-thinks-project-is-out-of-date-but-nothing-has-changed. sorry, searching `because "AlwaysCreate" was specified` didn't gave proper results, so i think i'll leave it open... – Hertzel Guinness May 19 '11 at 05:29
  • Sure no problem, if the possible duplicate doesnt solve your problem, indeed it is a different problem and you should keep it open. No worries :) – Alok Save May 19 '11 at 06:38

10 Answers10

46

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.

Bo Persson
  • 90,663
  • 31
  • 146
  • 203
  • 1
    Thanks. One of my headers was missing. – Hertzel Guinness May 19 '11 at 05:25
  • 6
    There is a very nice plugin available that shows the missing files in the error list: https://visualstudiogallery.msdn.microsoft.com/900b48cc-52b5-4afa-b4db-f1c3655c32aa – koch.trier Apr 19 '16 at 08:00
  • @koch.trier Except that this plugin doesn't support VS2010. – Andreas Haferburg Jul 13 '16 at 15:10
  • 1
    This. Same in VS2015. Mentioned [plugin](https://marketplace.visualstudio.com/items?itemName=DavidGardiner.ShowMissingFiles) works wonders. Side note: The missing header files in VS2015 are actually easy to find, as VS2015 adds a "▷" for each existing file in the Solution Explorer, but my project also had missing old resource file entries (removed bmp files) and the plugin also got these. – Martin Ba Nov 24 '16 at 09:44
  • In case anyone else runs into this: it's obvious, but if you changed your **system clock** to go back in time (for whatever reason), then that will lead to the "AlwaysCreate" situation. The plugin mentioned by @koch.trier showed all kinds of spurious CMake generated files, which threw me off. The solution in this case is to fix system clock, and/or touch all the files to fix their timestamps. – n00b101 Feb 21 '17 at 16:16
  • Even other missing files can cause problems: `1>Project not up to date because build input 'D:\prd\myproject\picture.ico' is missing.` – E. van Putten Oct 06 '17 at 09:58
  • @koch.trier 2020 nice but does not work for VS 2019 :( – NoSenseEtAl Jun 26 '20 at 10:29
37

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" />
Bzzt
  • 1,064
  • 8
  • 13
  • nice & useful on dark times (when you start to give extra names to a certain Bill...). – Hertzel Guinness Nov 10 '11 at 20:44
  • I recommend this! in a couple of minutes I was able to spot a few problematic files with DebugView and build times went down by 15% on the part of the project I worked on. I'm definitively going to do it for the whole project, where, I believe, the problem is worse :) edit: btw it was all missing files like Bo Persson said, DebugView just makes finding them easy – f4. Nov 20 '12 at 20:24
  • This was exactly my issue: compiling a second project, an application, triggered recompiling the first, the library. Since they shared a precompiled header. – geometrian Jan 26 '13 at 17:51
  • 4
    For VS2012 it's slightly different: http://blogs.msdn.com/b/andrewarnottms/archive/2012/06/07/enable-c-and-javascript-project-system-tracing.aspx – stijn Jul 06 '13 at 20:29
  • Above link for VS2012 blog entry is broken. – David V. Corbin Dec 29 '20 at 15:47
  • 1
    @DavidV.Corbin Google found it's https://devblogs.microsoft.com/premier-developer/enable-c-and-javascript-project-system-tracing/ nowadays. – Michel de Ruiter Apr 01 '21 at 13:10
8

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.

Community
  • 1
  • 1
Oded
  • 489,969
  • 99
  • 883
  • 1,009
  • 7
    Haha, this doesn't scale at all for big projects. – sorin Nov 04 '13 at 18:03
  • You can use diagnostic output (tools | options |Z projects and solutions | build and run and make the output diagnostic. Then search for "Project not up to date because" or even " missing" – doctorlove Oct 01 '18 at 11:50
2

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

Jacek
  • 41
  • 5
2

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

boatcoder
  • 17,525
  • 18
  • 114
  • 178
  • +1. After fixing a missing file, it still had the problem until I tried your solution, though I cleaned manually by removing all obj and bin folders. Finally, minimal rebuild works! – Ed Bayiates May 16 '14 at 18:53
0

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/

zizopen
  • 1
  • 1
0

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.

Vince
  • 91
  • 1
  • 3
0

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!

Matthew Lowe
  • 1
0

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:
Shane Gannon
  • 6,770
  • 7
  • 41
  • 64
0

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

GilesDMiddleton
  • 2,279
  • 22
  • 31