Take the 2-minute tour ×
Stack Overflow is a question and answer site for professional and enthusiast programmers. It's 100% free, no registration required.

I've a C++ project that I'm currently porting from VS2008 to VS2010. When I build the project, Visual Studio 2010 reports the build as successful but if I then press F5 to start the debugger I'm told that the project is not up to date. If I ignore this warning, I can continue debugging ok, but if I press ok, the whole project (many hundreds of source files), gets rebuilt from scratch. The output contains the following;

1>------ Build started: Project: SCCW-VC2010, Configuration: Debug Win32 ------
1>Build started 15/11/2010 14:47:40.
1>InitializeBuildStatus:
1>  Creating "Debug\SCCW-VC2010.unsuccessfulbuild" because "AlwaysCreate" was specified.
1>Midl:
1>  All outputs are up-to-date.
1>ClCompile:
1>  tinedit.cpp
1>  _WIN32_WINNT not defined. Defaulting to _WIN32_WINNT_MAXVER (see WinSDKVer.h)
1>  Automatically linking with sfl504d.lib
1>  Automatically linking with ot1104d.lib
1>c:\program files\rogue wave\stingray studio 10.4\include\toolkit\sectndlg.h(134): warning C4996: 'strcpy': This function or variable may be unsafe. Consider using strcpy_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details.
1>          c:\program files\microsoft visual studio 10.0\vc\include\string.h(105) : see declaration of 'strcpy'
1>  Automatically linking with og1204d.lib
1>  Automatically linking with RWUXThemeD10.lib
1>  profile.cpp
1>  ZOffsetDialog.cpp

Half an hour later, once the build is finished, the debugger starts. My guess is that the message

Creating "Debug\SCCW-VC2010.unsuccessfulbuild" because "AlwaysCreate" was specified.

is part of the problem, but I cant tie this to a project setting. I've found some help on google, but nothing that has worked thus far. Anyone else had this problem and know of a fix?

Edit: As per Jalf's suggestion in the comments below, I have created a new projected, imported all my files into that project, and the new project has the same problems. Specifically, I copied over all the following groups;

<ClCompile Include="..\MyDir\MyFile.cpp"/>
<ClInclude Include="..\MyDir\MyFile.h" />
<None Include="res\MyFile.ico" />  (and all similar resources)
<Library Include="..\MyDir\MyFile.lib" />

Edit2: After going through all the header includes I eventually found 3 that did not exist. Removing them and doing a rebuild all on the original project seems to have fixed the problem. Some of the blog posts that mention this problem refer to it as a bug, and two days of lost time later, I tend to agree. Thanks for the answers and comments provided.

Edit3: And one day later the problem is back! Making any edit to any file in the project once again causes a full rebuild. As per John Dibling's answer, the project does include some static libraries, including Stingray. I'm ditching VS2010 and moving back to VS2008, as I have deadlines. For related information, see the following links;

VS2010 always thinks project is out of date but nothing has changed

http://social.msdn.microsoft.com/Forums/en-US/vcgeneral/thread/38c08137-3bb0-4143-b97f-72d077646318

http://blogs.msdn.com/b/vsproject/archive/2009/07/21/enable-c-project-system-logging.aspx

Final Edit The release of VS2010 SP1 has solved this problem, and builds are now fast and efficient.

share|improve this question

7 Answers 7

up vote 5 down vote accepted

I've had this problem many times and it was always frustrating. I'll tell you what the problem was in my case, but first I have to ask you:

  • Did you do a rebuild-all before you tried running the first time, or just a rebuild?
  • Once you do a rebuild all, does it ask you yet again to rebuild if you've made no changes?

The problem in my case was somewhat complex. I had custom build rules that copies binaries for Stingray from their source directory (where they lived) to a directory in my build tree. The binaries were marked as a dependancy, so that they were copied before each build in case they changed.

The dependancy checked looked at the timestamps of these files to see when they were changed. If the blah.lib had a mod date of last December in it's source directory, then when it was copied it would have the same mod date. The dependancy checked would note that "hey this file's pretty old, we have to rebuild it," and then it would ask if I wanted to do a full rebuild.

For a while I got by by just saying "No," but eventually I fixed the problem by changing the custom build rule to write a new text file after it did the file copy. That would make the new text file the dependancy, and not the blah.lib file, and it made the compiler happy.

share|improve this answer
  1. See in output window what file is rebuild

  2. Set Tools->Project and Solutions->Build and Run->MSBuild Project build output verbosity to

    Diagnostic
    
  3. Build, got long log

  4. Find file (from 1) in log, read diagnostic. You may found for example header name which has date in future or absent.

share|improve this answer

The MSDN docs imply that this property is specific to deployment projects.

findstr /si AlwaysCreate on your VS2010 project files should show you the culprit(s) if you can't track it down in the GUI.

share|improve this answer

I had the same problem on both converted and from-scratch projects. I got a hint from a MS page about missing files. I checked my project and found that it referenced a file that did not exist. Replaced it with the correct file, and the problem went away.

share|improve this answer

I know this is a very, very old post but for the benefit of all who still have this problem I decided to post my input. because "AlwaysCreate" was specified has nothing to do with project being rebuilt.

IT is the other way around. If you or Visual Studio decides to rebuild all, this causes creation of the "*.unsuccessfulbuild" file.

Some other issue (usually header that does not exist) will cause rebuild all leading to displaying because "AlwaysCreate" was specified.

"AlwaysCreate" is a part of Visual Studio build environment settings and is part of the Microsoft.CppBuild.targets XML file. It contains following line: Touch AlwaysCreate="true" Files="$(LastBuildUnsuccessful)"/

It this is set to true, ".unsuccessfulbuild" file will always be created regardless of the build being successful or not. If this is changed to false, ".unsuccessfulbuild is not created. If true the *.unsuccessfulbuild file is created as empty for the duration of the build process and then delete if build is successful. I am not sure why this file is created; even if the build has errors, the file is empty but not deleted as in case of the successful build.

Possibly the existence of this file has some meaning known only to VS build environment. If you want to play with this setting, deleting Touch key from

share|improve this answer

Decided to revisit this with the release version of SP1. I recreated a new project from scratch, which came out at 81k compared to the upgraded older project of 1.4mb which was carrying all sorts of junk with it. Initially, I came across the same problem, but managed to resolve it as follows;

  • Changed pre-compiled headers to Create (/Yc)
  • Compiled one source file
  • Changed pre-compiled headers to Use (/Yu)
  • Did a full rebuild

Next problem I noticed was that any resource addition was causing a recompile of all files containing including resource.h This was fixed using advice from the following Microsoft connect thread and manually adding the following lines to my project;

<ItemGroup>
    <ClNoDependencies Include="Resource.h" />
</ItemGroup>
share|improve this answer

In my case it seemed to help to build the deployment project(s). I have set them not to build when I hit F7 but manually. Some people suggest creating a new solution + projects but that's not a very good option when the projects have a lot of manual tweaking and custom build rules.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.
{"cc_re__cc_re__cc_by_sa_3_0": ["                  <li><a href=\"//area51.stackexchange.com\" title=\"proposing new sites in the Stack Exchange network\">Area 51</a></li>\r\n                        <li><a href=\"//careers.stackoverflow.com\">Stack Overflow Careers</a></li>\r\n                    \r\n                </ol>\r\n            </td>\r\n    </tr>\r\n</table>\r\n                </div>\r\n            </div>\r\n\r\n            <div id=\"copyright\">\r\n                site design / logo &#169; 2015 stack exchange inc; user contributions licensed under <a href=\"http://creativecommons.org/licenses/by-sa/3.0/\" rel=\"license\">cc by-sa 3.0</a> \r\n                with <a href=\"http://blog.stackoverflow.com/2009/06/attribution-required/\" rel=\"license\">attribution required</a>\r\n            </div>\r\n            <div id=\"svnrev\">\r\n                rev 2015.3.30.2414\r\n            </div>\r\n            \r\n        </div>\r\n    </div>\r\n    <noscript>\r\n        <div id=\"noscript-warning\">Stack Overflow works best with JavaScript enabled<img src=\"http://pixel.quantserve.com/pixel/p-c1rF4kxgLUzNc.gif\" alt=\"\" class=\"dno\"></div>\r\n    </nos"], "copyright__copyright__copyright": ["y case it seemed to help to build the deployment project(s). I have set them not to build when I hit F7 but manually. Some people suggest creating a new solution + projects but that's not a very good option when the projects have a lot of manual tweaking and custom build rules.\n\nshare|improve this answer\n\nYour Answer\n\n\u00a0\ndiscard\n\nBy posting your answer, you agree to the privacy policy and terms of service.\n\nNot the answer you're looking for? Browse other questions tagged or ask your own question."]}