Visual Studio keeps asking to rebuild project

I recently switched to VS2010 from VS 6.0. I've converted my project and compiled successfully. But everytime I run the program from VS (ie by click "Start Debugging" or "Start without Debugging"), VS reports that the project is out of date and asks to build it, even though I had just finished building it. This occurs in both Debug and Release configurations.

Here is the output window if it helps:

Code:

---

1>------ Build started: Project: ConfigTool, Configuration: Release Win32 ------
1>Build started 5/4/2011 6:30:59 PM.
1>InitializeBuildStatus:
1>  Creating ".\Release\ConfigTool.unsuccessfulbuild" because "AlwaysCreate" was specified.
1>ClCompile:
1>  All outputs are up-to-date.
1>  All outputs are up-to-date.
1>ResourceCompile:
1>  All outputs are up-to-date.
1>Link:
1>  All outputs are up-to-date.
1>  ConfigTool.vcxproj -> C:\Visual Studio 2010\Projects\ConfigTool\.\Release\ConfigTool.exe
1>Manifest:
1>  All outputs are up-to-date.
1>FinalizeBuildStatus:
1>  Deleting file ".\Release\ConfigTool.unsuccessfulbuild".
1>  Touching ".\Release\ConfigTool.lastbuildstate".
1>
1>Build succeeded.
1>
1>Time Elapsed 00:00:00.07
========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========

---

Hi,

I've only seen this if any files were saved "in the future", e.g. if your PC date was set incorrectly at some stage and you saved a file.

Alan

I have this problem quite often in VS2005 and I've found that the solution is to compile any changed files (CTRL+F7) and then - only after all changed files are compiled - select 'Build'. If I perform the compile and link in one operation (selecting 'Build' straight away or just pressing F7) I almost always get this problem.

If that doesn't fix it, the most likely explanation is that you've got one or more source files depending on a header file with a more recent date. Whenever I modify a header file I routinely set its date to some date that's a long time in the past, just to avoid this. Of course, you do end up having to do a full Rebuild (once) but that's a lot better than seeing this problem all the time.

Try to make sure that all your header files are dated a long time ago.

What is your “MSBuild project build output verbosity”?
It is in Tools->Options->Projects and Solutions->Build and Run.
Try setting it to Detailed and see if you get more info.

This has happened on every single install of VS2010 I've ever seen. I think it's a bug in the IDE. Just say "Don't ask again" and ignore it----the extra time used is minimal.

@John E:
Separating the compile and build step didn't fix the problem. It would still ask to rebuild.
I don't know how to set the modify date of a file as you mention, but I made sure all source files are more recent than header files. No luck with this either.


@VladimirF:
Here is the detailed output. I can't make sense of all of it, but maybe someone here can.
See attached txt file, the forum won't let me post such a long text.

@Lindley:
So this is a known bug?
I don't want to disable the rebuild check because there are occasions when this feature comes in handy, like when I forget to build after making a change.

I created a new test project entirely in VS2010 (instead of converting an old project). I do not get the same issue. After building once, it does not ask again when I run the program. So it must have to do with the conversion from old project...

Quote:

---

Originally Posted by acerunner316

I created a new test project entirely in VS2010 (instead of converting an old project). I do not get the same issue. After building once, it does not ask again when I run the program. So it must have to do with the conversion from old project...

---

Did you specify something under the 'custom build step' in the project settings? I've seen that cause such behavior. Moving the task from the custom build step to the post build solved it.

Otherwise, check the differences between both project files. They are just text files, so you can easily compare them.

Quote:

---

Originally Posted by acerunner316

@Lindley:
So this is a known bug?

---

Known to me, anyway. It's always possible both of us are doing the same thing wrong.

Quote:

---

Originally Posted by acerunner316

I created a new test project entirely in VS2010 (instead of converting an old project). I do not get the same issue. After building once, it does not ask again when I run the program. So it must have to do with the conversion from old project...

---

That's an interesting insight. Now you mention it, all my existing VS2005 projects were converted from VC++6 and I often do get the same problem. Those fixes I mentioned work very reliably for me though.

In VS2010, this problem is typically casued by a header file that has been physically deleted, but, not removed from the project. You can determine what header it is by enabling Project System Logging. It's not a good idea to use the build flag to turn off the out-of-date warning since it may be a legitimate problem with the build.

Mike Harnad's might be on to something.

i tried a full rebuild - even manually deleted the .suo, .sdf, and any other files that aren't required. nothing worked.

Mike suggested that a header could be missing but still in the project. I went through all the files that were in my project and double clicked them - thinking that if one had been deleted it wouldn't open. One of the header files popped up an error message - something about the text viewer not being able to be opened (in all my programming years i've never seen that window and unfortunately i didn't write down the exact message).

anyway, i removed that header file from my project (the project uses it, but it was an inline header). performed a rebuild all - and bam! fixed!

i think maybe the project entry for that header had somehow been corrupted.

I happened to be haunted by a quite similar problem during the last days, so this bubbled-up thread came in really handy to me. :)

In my case it wasn't a future-timestamped file that caused the problem, but a bunch of files with creation dates after their modification dates. This can happen quite easily when copying files between projects, or, much worse, when scraping the entire project and restoring it from a backup. Resetting the creation date to the modification date fixed the issue. (The debug configuration needed a clean-up run before this became effective while the release config didn't, for unknown reasons, but then again, hey, it works! :)) The opposite manipulation probably would help as well, but would trigger a lot of unnecessary rebuilds, though only once.

Interestingly, the app.ico file put into any (non-console) project by the IDE by default, always suffers from the same defect without any adverse effect, but perhaps they simply hacked away the sensitivity to this quirk for this particular file... :rolleyes:

Hope this will help someone who reads it later...

If this is VS2010, then this can be caused by a de-syncing of what the ID knows, and what the build system (i.e. MSBuild) has to work off.

Try if a REBUILD solves the problem.

It can also happen if one of the files has a custom build step which has an "output" defined, but the custom build step does not actually create this outputfile. from your build log, that doesn't seem to be the case here though.

All,

There's no reason to guess at the cause. If you follow the link in my prior response and implement the IDE configuration tweak it speaks of, you'll know what the exact cause is.

Quote:

---

Originally Posted by Mike Harnad

There's no reason to guess at the cause. [...]

---

After this thread had hinted me to the fact that the cause might be a timestamp screw-up (which, with hindsight, looks like a quite natural reason... :o), there was not much guessing involved for me at all. It took me a few minutes to figure out the screw-up, then one hour and 71 lines of C++/CLI to hack together a first working version of a command line tool to sweep-fix that quirk over an entire solution's directory tree (or whatever tree I want, for that matter). (And, actually, in the meantime I could use that tool one more time. :))

Before I found the thread, however, I had spent hours of searching for some sort of weird hidden dependency, that, as I do know now, I couldn't find of course. :o During this process I also experimented with the MSBuild output verbosity level as can be set in the IDE preferences, and to me, already the detailed output rather was too much information in which I didn't find what I was looking for. (And now it looks like it wouldn't have been there anyway.) Didn't even touch the diagnostic level...

The most valueable effect of your link for me, however, actually rather was a side effect: It made me read up on that .NET diagnostic switch facility, of which I already knew it existed, but otherwise ignored it for the most part. And it turned out that this can pretty much simplify a lot of diagnostic stuff I currently do using "homegrown" app.config properties I read in as strings and then process entirely on my own. Also, it gave me some ideas how I might improve my own logger module by tighter integrating it with the existing .NET diagnostics infrastructure. Thanks! :thumb: :)