Home Dashboard Directory Help
Search

Suggestion: Help me diagnose issues causing "This project is out of date" message by jschroedl


Status: 

Closed
 as Fixed Help for as Fixed


5
0
Sign in
to vote
Type: Suggestion
ID: 653355
Opened: 3/24/2011 10:10:12 AM
Access Restriction: Public
1
Workaround(s)
view

Description

In my C++ build I often attempt to debug (F5) and am hit unexpectedly with the "This project is out of date: myproject - Debug Win32" message box.

This can show up due to a variety of reasons such as:
* A source or header file changed and object code needs to be rebuilt. (the usual, normal reason for the message)
* There is a header erroneously listed in the project filters. ie. a dev deleted a file but forgot to remove it from the filters.
* There is a generated header file which needs to be created.
* Other unexpected issues with the solution.

I'm in a situation right now where this message shows EVERY time I attempt to debug even though I just built the project and all the files seems to be in-place and have the correct time stamp.

So... I'm stuck. I would like a link or button next to each entry in the list on the "This project is out of date" dialog labeled something like "Why is it out of date?" or "Show Me" or "Details..." and it would show me why msbuild/VS feels the need to rebuild my project.

example output I'd appreciate:
"File: C:\foo\bar.h not found. Possibly a generated header file?"

"File: C:\foo\bar.cpp newer than C:\foo\int\bar.obj"

"File C:\foot\bar.h modified"

You get the picture I hope. This way, I can try and fix a problem if I keep getting this message unexpectedly.

If the UI is unchangeable, I would LOVE it if there could be a VS Extension which does the same rule evaluation and creates a report with the same information.
Details
Sign in to post a comment.
Posted by psc_wanko on 12/27/2011 at 12:22 AM
I have now a similar problem. I start Debug with F5 and get folow message:
'D:\ws_psc\pra\proj32\WkTool\WkTool.vcxproj' not up to date because 'C:\DOKUMENTE UND EINSTELLUNGEN\ALL USERS\ANWENDUNGSDATEN\SOPHOS\SOPHOS ANTI-VIRUS\CONFIG\CONFIG.BOPS' was modified at 12/27/2011 08:29:44, which is newer than 'D:\WS_PSC\PRA\PROJ32\WKTOOL\DEBUG\WKTOOL.DLL' which was modified at 12/27/2011 07:22:42.     

This message I got by activate of system information of Visual Studio. It's interesting, that VS check anti-virus settings. Does somebody hav a same problem?
Posted by _s_s_ on 8/17/2011 at 1:55 AM
I can reproduce this issue easily.

https://connect.microsoft.com/VisualStudio/feedback/details/684476/this-project-is-out-of-date-after-remove-some-files-from-vs-and-delete-the-files-from-the-disk#details
Posted by Microsoft on 8/5/2011 at 4:11 PM
Thank you for your feedback. Please take a look at this blog post that describes how the project system can be made to log messages which will help you diagnose your up-to-date check problems:
http://blogs.msdn.com/b/vsproject/archive/2009/07/21/enable-c-project-system-logging.aspx
Posted by jschroedl on 5/23/2011 at 6:49 AM
Sean, I'm still convinced that there is a bug with the msbuild <--> devenv connection especially when files are retrieved from source control outside of Visual Studio. We've hit this multiple times.

The only solution I've found is the need to periodically del /s *.tlog under my solution dir from a command prompt.

John
Posted by Sean Kinsey on 5/11/2011 at 3:02 AM
I think I'm getting the same problem. I have a solution that was converted from VS2008 to VS2010sp1. Everything was fine under VS2008. With VS2010 I rebuild my application and then hit F5 and I immediately get hit with a dialog stating that one of my Cpp projects is out of date. This happens every time I hit F5 (incredibly tedious).
Posted by Microsoft on 3/29/2011 at 8:53 AM
Thanks for getting to the bottom of this.

Based on your information, it looks like the behavior is caused by the communication between the IDE and MSBuild. The IDE looks at all the tlog files and decides whether the build is up-to-date. If it isn't, it delegates to MSBuild to build the project. MSBuild correctly finds that there is nothing to build and says that in the buildlog. If there were any new files, or any files changed, you would get a similar message in the output window to the one you suggested.

The IDE doesn't by default share the same level of information. There are ways to make it more verbose too though. Check out Andrew's blog post that talks exactly about how to make IDE Up-To-Date Checks share more information about its decisions: http://blogs.msdn.com/b/vsproject/archive/2009/07/21/enable-c-project-system-logging.aspx

Thanks,
Marian Luparu
Visual C++
Posted by jschroedl on 3/29/2011 at 8:09 AM
Deleting the tlog files and rebuilding fixes my problem. There is clearly a bug with either CL or msbuild whereby a project change is not detected and the tlog files contain stale information.

When my suggestion is implemented (stop laughing), I'd see a message like:

"File C:\xxxxx\noLongerInProject.cpp found in CL.read.1.tlog but C:\xxxx\noLongerInProject.obj does not exist"

That way, I'd think "hmmm, that frigging tlog file is wrong again I need to delete all of those".

We need help here. I should not need to spend a day on this!
Posted by jschroedl on 3/29/2011 at 6:14 AM
Looking through the detailed output, the CL.*.read.1.tlog files are consulted for dependency information. There are a lot of those files in the Int directory, most are 2 bytes long and empty. CL.read.1.tlog file has lots of content but much of it is out-of-date (ex. it lists .cpp files which are no longer in the project). So this would appear to be a problem that the .tlog file is bad.

How did it became bad and how are they regenerated is a mystery.

FYI - I see this is still marked as Closed when it should be Active.
Posted by jschroedl on 3/28/2011 at 1:13 PM
I've attached the output with "Detailed" msbuild setting in case you see something I am missing in there.
Posted by jschroedl on 3/28/2011 at 1:09 PM
Thank you for reconsidering. I cannot readily tell that is causing the rebuild as it reports everything as up-to-date. Here is the build output from an attempt I just made note that everything seems up-to-date yet these steps are repeated on every attempt to debug.

1>------ Build started: Project: scintilla, Configuration: Release Win32 ------
1>Build started 3/28/2011 4:01:33 PM.
1>InitializeBuildStatus:
1> Creating "C:\JMPDev\source\WinOS\build\Win32\Release\scintilla\Int\scintilla.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> scintilla.vcxproj -> C:\JMPDev\source\WinOS\build\Win32\Release\scintilla\scintilla.lib
1>FinalizeBuildStatus:
1> Deleting file "C:\JMPDev\source\WinOS\build\Win32\Release\scintilla\Int\scintilla.unsuccessfulbuild".
1> Touching "C:\JMPDev\source\WinOS\build\Win32\Release\scintilla\Int\scintilla.lastbuildstate".
1>
1>Build succeeded.
1>
1>Time Elapsed 00:00:00.27
2>------ Build started: Project: Jmp, Configuration: Release Win32 ------
2>Build started 3/28/2011 4:01:33 PM.
2>ResolveAssemblyReferences:
2> A TargetFramework profile exclusion list will be generated.
2>InitializeBuildStatus:
2> Creating ".\Win32\Release\Jmp\Int\Jmp.unsuccessfulbuild" because "AlwaysCreate" was specified.
2>CustomBuild:
2> All outputs are up-to-date.
2>_MASM:
2>Skipping target "_MASM" because all output files are up-to-date with respect to the input files.
2>Midl:
2> All outputs are up-to-date.
2>ClCompile:
2> All outputs are up-to-date.
2> All outputs are up-to-date.
2> All outputs are up-to-date.
2> All outputs are up-to-date.
2> All outputs are up-to-date.
2>ResourceCompile:
2> All outputs are up-to-date.
2>Link:
2> All outputs are up-to-date.
2> Jmp.vcxproj -> C:\JMPDev\source\WinOS\build\Win32\Release\Jmp\Jmp.exe
2>Manifest:
2> All outputs are up-to-date.
2>PostBuildEvent:
2> Description: Run post-build copy scripts (Xstr, jmptojava). . . .
2> Microsoft (R) .NET Framework Type Library to Assembly Converter 4.0.30319.1
2> Copyright (C) Microsoft Corporation. All rights reserved.
2>
2> TlbImp : Type library imported to C:\JMPDev\source\WinOS\build\Interop.JMP.dll
2>FinalizeBuildStatus:
2> Deleting file ".\Win32\Release\Jmp\Int\Jmp.unsuccessfulbuild".
2> Touching ".\Win32\Release\Jmp\Int\Jmp.lastbuildstate".
2>
2>Build succeeded.
2>
2>Time Elapsed 00:00:05.91
========== Build: 2 succeeded, 0 failed, 9 up-to-date, 0 skipped ==========


If I switch to "Detailed" msbuild verbosity, I see the message before any output in the Output pane. I'm about to pore through that output anyway and see if it offers any clues.

To repeat my pleaa, this is exactly why I need a report with an explanation of why it insists on building. I'm VS-savvy and this is painful, imagine trying to help a statistician figure this crap out!
Posted by Microsoft on 3/28/2011 at 12:31 PM
Hello, we missed the fact that this happens all the time in your build. Sorry about that. I reactivated the bug.

If you're already using VS2010, the good news is that the C++ build process diagnostics has vastly improved.

Follow the following steps to get more information about your rebuild problem:
- identify what's the first thing that causes a rebuild. E.g. is it the Compile step, or maybe the .rc file rebuilding, or maybe it's only the link step getting called repeatedly.
- Go to Tools > Options > Project and Solutions > Build and Run and flip "MSBuild project build output verbosity" to "Detailed".
- trigger another incremental build again
- search in the very verbose output for the offending file or step
- in the description of the step, there should be a clear message why MSBuild decided to invoke the command.

Please post back your findings. If the "Detailed" log doesn't provide you with enough information on why the rebuild occurs, we'd like to investigate this further.

Thanks,
Marian Luparu
Visual C++
Posted by jschroedl on 3/25/2011 at 9:00 AM
Clearly you do not understand my point. I am SO ANGRY that this is marked Closed By Design and disissed out of hand. This is a perfectly reasonable request.

I KNOW this is a standard C++ message since 2002. It's been a problem since 2002!!!!

The point, is that doing a rebuild does NOT fix the problem. If I build then immediately press F5 it tells me the project is still out of date. Building again, and again and again will NOT fix the issue.

The point is that I don't know WHY it wants to build so I CANNOT fix the problem.

I do NOT want to hide these messages, I want to know WHY the message was shown to me. In DETAIL!

Please re-open this suggestion. I would like it considered by the developers as something that will save C++ devs time and frustration.
Posted by Microsoft on 3/25/2011 at 8:41 AM
Hi, what you are seeing is a standard C++ build system message that has been around since VS 2002. What it means is that due to the change you have made in the source file, the binaries on disk that were built last time from these sources are "out of date" comparing to the current source. All you need to do is to build the project again before debugging. Otherwise, your breakpoint may end up on the wrong lines of source code. This does not indicate that there is anything wrong with your project or the Visual Studio.

If you prefer not to see this message again, there is a little checkbox at the bottom of this dialog that allows you to turn it off. Each time you press F5, your project will build without asking you.

Hope this helps.

Rui Sun
Visual Studio Diagnostics Team
Posted by small_mountain_0705 on 3/24/2011 at 10:14 AM
My project is in exactly the same state right now. It is extremely annoying.
Posted by Microsoft on 3/24/2011 at 10:14 AM
Thank you for your feedback, we are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(http://support.microsoft.com)
Sign in to post a workaround.
Posted by DigitalBlue on 1/17/2012 at 8:23 AM
I saw this behavior on a computer recently and noticed that there was an antivirus program running. It was actively scanning every file opened by the operating system. When this was disabled, Visual Studio seemed to properly "remember" that everything was built and did not insist on rebuilding the entire project when it was not otherwise necessary.
File Name Submitted By Submitted On File Size  
Detailed Build 1.txt (restricted) 3/28/2011 -
Detailed Build 1.txt 3/28/2011 394 KB