I've been trying to get Visual C++ working, but I'm getting this error when building every project: "This project is out of date" "Would you like to build it?" It fails to build every time.
When I rebuild, the build still fails, although in the logger I don't notice any error messages, which makes me think its not logging properly (I'm using a third party program to log).
I've followed some of the instructions here: http://blogs.msdn.com/b/vsproject/archive/2009/07/21/enable-c-project-system-logging.aspx and enabled logging.
I'm getting this error: project not up to date because "insert file name here".lastbuildstate is missing. Note that in actual visual studio, there is nothing logged. I was unable to find anything on this in google. It may be that I incorrectly enabled logging, but I feel that this is the error.
You should let Visual Studio tell you why it needs to rebuild. Visual Studio 2015 has built in support for this:
Tools (menu)
Options
Project and Solution
Build and Run
Change MSBuild project build output verbosity to Detailed or Diagnostics.
In my case it printed a message like this:
1>------ Up-To-Date check: Project: xyz, Configuration: xyz ------
1>Project not up to date because build input 'C:\ws\Missing.h' is missing.
... and removing that header from the project fixed the problem.
To get this information in older Visual Studio versions, you need to use DebugView and modify devenv.exe.config (see Colin Smith's answer: https://stackoverflow.com/a/21759835/1941779). Note that this solution does NOT work for Visual Studio 2015.
What are "tlog" files?
"tlog" files are created by the "Tracker.exe" process which runs while you do a build, and records some information about the build.
That information is used and updated the next time you start a build to help detect "out of date" files, and thus enable the build system to only build the bits that need to be rebuilt (rather than building everything again).
File Tracker Log file format
https://social.msdn.microsoft.com/Forums/vstudio/en-US/67705333-a425-4d6e-9881-9077f044f87a/how-do-i-prevent-msbuild-from-creating-tlog-files-during-my-c-builds?forum=msbuild
https://dickyjim.wordpress.com/tag/tlog-files/
What causes the "out of date" problem?
The problem can be caused by incorrect or stale information in the *.tlog files.
There are 3 main ways that can happen:
1) You built a project on your hard disk, and then moved the directory to another location...the "tlog" files recorded the paths of the old location, yet because you moved the files, they are no longer there, thus you get "out of date".
2) Your "Project" has references to files (usually header files), which do not exist at the location specified. This might occur if you deleted a file from your source control system, but forgot to remove it from your project, or because you refer to header files of a library which might be "installed"/present at a different location. Often, Developers assume files are located at the same "place" on everyones machine....not always the case!
3) You have done some "refactoring" of your project, and moved files around to different subdirectories, or even renamed them - so the paths/names of the files recorded in the "tlog" do not match what exists on your disk i.e. stale.
What is the way to fix it?
Doing a "Clean+Build" or "Rebuild" does not always fix it...as those operations do not delete the "tlog" files. So:
delete any "tlog" files that you can find in your solution/project directories and rebuild.
make sure your Project does not refer to non-existent files
How do I work out which files are non-existent?
If you want to know/find out exactly which files Visual Studio is thinking are out of date, then you can turn on some diagnostic information in Visual Studio....and watch the messages in DebugView...showing the full path of the files it is probing.
http://blogs.msdn.com/b/vsproject/archive/2009/07/21/enable-c-project-system-logging.aspx
In devenv.exe.config you put:
<system.diagnostics>
<switches>
<add name="CPS" value="4" />
</switches>
</system.diagnostics>
More Details
Lets say you created a Solution and a set of Projects in a particular directory e.g. S:\MYPROJECTS, and you compile and run/debug it, etc.
You then decide to move that whole directory to somewhere else on your drive, or you re-factor your Projects e.g. change their directory names, etc.
Now when you do a "Start Debugging/F5", Visual Studio does the depending checking, and thinks you have "out of date files".
Even if you do a "Clean Solution", or a "Rebuild Solution"....you still get the "out of date files" message.
See here:
http://connect.microsoft.com/VisualStudio/feedback/details/653355/suggestion-help-me-diagnose-issues-causing-this-project-is-out-of-date-message
The problem is caused by the ".tlog" files which are being consulted during the dependency checks...when you moved the solutions/projects (along with a builds intermediate files) they cause confusion to the Visual Studio builder.
The solution is to delete all the .tlog files.....they will then be re-generated the next time you do a build...and from that point on you won't get a bogus "out of date files" message....unless they truly are out of date.
I too kept getting "The project out-of-date" error, even though there were no changes. I traced it to a header file listed in Solution Explorer that was no longer being used and had been deleted from the project's directory. Removing it from the SE list fixed the extraneous error message from popping up.
I had this problem, too.
In my case the reason was the references to files (usually header files), which do not exist at the location specified.
I ran into this problem and, using the diagnostics trick that colinsmith posted about, was able to trace the problem back to the fact that my .vcxproj was referencing a file that didn't actually exist anywhere (It had been deleted a long time ago, but never removed from the project file).
Just for posterity, I was getting this problem, and then realized my computer clock had somehow jumped approximately 48 hours into the past. After I set it back to current time, the warning went away.
Related
I was beginning to use Visual Studio 2013 to work with OpenCV.
I had completed a simple project that I need and was just doing some cleanup.
The compiler begin giving the message.
error C1083: Cannot open source file:
What I have tried so far:
Creating a new console application in a separate file and trying to compile it, just created . -> same error.
Repairing Visual Studio using the original installation disk. -> same result on new just created project "error c1083;
Uninstalling Visual Studio and then reinstalling it. -> same result on new just created project "error c1083"
Things I have noticed. My compiler is not creating a .pch file or at least I cannot find it. I have precompiled headers enabled. /Yc for stdafx.cpp and /Yu. for other files if I have any.
If I use a previously created project that was working the IDE will run it, but if I change anything in the source file I get the same error.
I have tried placing projects in very short paths and in the normal location for the compiler.
Solution explorer sees and will open the source file.
I am beginning to think something is corrupted in my operating system. (Windows 7).
I have been thinking I might format the disk and reinstall Windows, but thought I might ask for suggestions on this problem first.
"
What do you mean by 'doing some cleanup'? It is quite unlikely that your OS is corrupted. There is probably something wrong with your project properties, but I couldn't tell you what without better information"
This was just a simple project to place cross hairs on the input from a USB microscope which was spindle mounted on a CNC milling machine for centering purposes. I was just changing the on screen position and size of the cross hairs. Then when I recompiled the problem started. I thought it might be a corrupted file because of the fact that it persisted after uninstalling and reinstalling Visual Studio. The fact that a freshly generated project would not compile made me suspicious.
"
Looks like something in your Project/Properties is not right. It is looking for the files in the wrong directory"
You are probably correct, but I am a novice and have spent many hours trying to find what it may be any suggestions for what settings to change would be greatly appreciated.
"
Do your TMP and TEMP environment variables point to directories that (1) exist (2) you have write permission to and (3) have free space? "
Yes sir The environment variables are set and the directory has read write permission. There is > 1T of free disk space.
"
Also try (with VS closed) deleting the registry keys HKCU\Software\Microsoft\VisualStudio\12.0 and 12.0_Config and the directory %LOCALAPPDATA%\Microsoft\VisualStudio\12.0, then open VS and try again with a fresh project. This will cause VS to regenerate all caches and "transient" information (it will also reset all your settings, so beware)."
Sir: I deleted the keys and the directory you recommended, generated a fresh project and tried to compile it. The compiler generated the same error. I genuinely appreciate the suggestion.
"VS only allows closed source development"
Pointed, consider the source of VS.
When I go to debug my C++ project in Visual Studio, up pops a little warning dialogue box that tells me:
A copy of datum.h was found in
c:/users/brad/desktop/source/binary/datum.h, but the current
source code is different from the version built into
c:/users/brad/desktop/source/binary/datum.h.
I'm having trouble understanding what this is even trying to tell me, let alone how to fix it. At first I thought it might be complaining that I'd accidentally duplicated a file in the directory, which I checked, and found nothing of the sort, which leaves me pretty stumped. I also tried excluding the file from the solution and adding it again, which didn't fix the problem either.
The warning doesn't appear to actually hinder the development of my project, but I suppose warnings exist for a reason, so if anyone knows what's gone wrong, any advice would be greatly appreciated. To my knowledge, I didn't change anything to cause the message to appear, it just popped up one time I went to debug the solution and has kept on appearing ever since.
Also, more copies of the same warning have started popping up, pertaining to other header files in my solution (I haven't recieved any about .cpp files yet, but it could be a coincidence, because it's only been going on for about 20 minutes).
Try removing breakpoints from the file in question.
This worked for me when it occurred with Visual Studio 2013 for a header file in debug build.
Source: Release mode file sync issue - current source code different from the version built
Additional notes: Clean / Rebuild also works, but that is painful for regularly changing code. Enabling the break point after starting debugger merely delays the message.
I solved it:
Close the window of the .h file in Visual Studio if it's open.
Close Visual Studio.
CUT the .h file from its normal location and paste it into a temporary folder that VS doesn't know about.
Restart VS and compile. It'll complain about the missing .h file. Good -- Make the bastard beg for it!
Paste the .h file back into its original location.
Compile. VS will gratefully accept the missing file. (Damn I hate Microsoft!)
This occurs if you rename an implementation file (*.c, *.cpp, etc.) to a header file.
This is because the Item Type still remains as C/C++ Source File, making it get compiled as a separate translation unit rather than as an actual header, preventing Visual Studio from recognizing its inclusion as a header elsewhere.
It took me quite a while to figure this out.
To fix this:
Right-click your header file in Solution Explorer and select Properties.
Select All Configurations, All Platforms.
Under General, change Item Type to C/C++ Header.
Press OK.
Force-recompile any file that #includes your header (or just Rebuild the solution).
The problem is that the debugger thinks that the checksum of the source file is different from what the compiler calculated and put in there. The debugger will then refuse to apply breakpoints in the files that mis-match, to prevent you from seeing data it can't guarantee is correct.
I have had this keep happening even after a clean rebuild. This is with VS 2015. My guess is perhaps the debugger and the compiler disagree on how to hash newlines or something like that? The fix is to turn off "require source files to exactly match the original version" in Debug -> Options -> Debugging -> General
Could you by any chance be debugging another executable (not the one actually built?). This is a common issue in scenarios where Visual Studio builds the binaries in one directory but then they are copied over to some other directory for debugging. I'd suggest you compare the target path under the debugging settings and the output directory under the general settings in Visual Studio.
This would explain the issue, since you are actually debugging some older version of the binary (not the one built currently) and thus the warning, since Visual Studio can't find the version of the source files for that version of the binary.
The reason may be circular header dependencies. datum.h may includes another_header.h (directly or indirectly), which includes datum.h.
I see the real reason of this question is not answered. So for someone still looking, here it goes...
The most common reason of this problem is that the source files used to build the existing obj files are different than the existing ones. In other words the
particular project did not build after new modifications to source. The solution to this problem is to rebuild the project after modifying.
This happened to me in situation where I had modified my static library projects files and then without building that project I started my application project which was using this static library project.
this worked for me:
close VS
delete *.vcxproj.filters file
restart VS
problem should be gone.
this worked for me:
clean project
debug/delete all breakpoints :)
This worked for me (as of March 2019):
Click the 'Build' drop-down menu in the top left of your Visual Studio window
Select 'Rebuild Solution'
I've changed the file name and it works now.
Just encountered this. In my case, one of my .h files contained implementation (a class with static methods), which was #included by one of my .cpp files, but the Project Settings were also telling Visual Studio to compile the .h file.
I manually edited both the .vcxproj and .vcxproj.filters project files, moving the .h file from the <ClCompile> ItemGroup to the <ClInclude> ItemGroup.
This did the trick for me; I never saw the "A copy of...is different from..." pop-up again.(Note that this was after I had thoroughly failed in attempts to get <DependentUpon> to work.)
My solutiion:
Build -> Configuration manager
Switch to another configuration (any, example Releas or Debug)
Switch to previous configuration
It is possible to have multiple projects, each with their own entry point within a solution. Make sure that the correct project is being run.
The source code is different message can appear in a project A's source when you are running project B. In this case, the message can mean This breakpoint won't be hit because you're running a project that doesn't include it
I'm having a problem with Visual Studio not invoking msbuild to actually build my solution. Invoking msbuild from the commandline results in a proper build, but in Visual Studio starting build results in an "everything is up to date" message. Manually compiling a .cpp file seems to partially or fully fix the problem.
Restarting VS2010 does not correct the problem, so I feel like VS2010 must be writing its own dependency information somewhere. By dependency information I mean what files actually require building, AKA which files have been altered since the last successful build.
Does VS2010 perform it's own dependency checking before invoking msbuild? Where does it store this information?
To force a build to occur from the Visual Studio GUI you can select "Rebuild All". That will trigger compilation of all your source files.
The problem with regular builds not working could be related to incorrect clock settings in your PC. Make sure your system clock is correct, including the time zone. Then do a project 'clean' and try to build again.
My Dad says to check your "obj folder" and clean it out. VS2010 is seeing that there are things on there so it assumes there's nothing new to build.
I've seen this kind of behavior occasionally, though I can't explain how it gets corrupted.
Try deleting all the intermediate files: everything in the Debug and Release directories, plus the project name files of types .suo, .ncb, and .aps. Then rebuild all.
If you are experiencing the same behavior as I do, this tends to make VS work properly for awhile—a few weeks or 50-100 builds (whichever comes first).
I have built a particular dll with debug information (compiler option /Zi and linker option /DEBUG). Through an interrupt statement in the main program, I launched the Visual Studio for debugging. In the list of modules shown as seen from Debug->Windows menu, I could see that the symbols have been loaded for the dll interested in. However when I open a C++ file from that dll and try to set a breakpoint, it says debug symbols are not available for the document. There is no question that this C++ file was compiled into that dll, and that it is the same source used to build the dll (I only did it). Why does this happen? Please help, before I shoot myself.
I don't have a definitive answer, only a few suggestions.
Sometimes mdm.exe (Machine Debug Manager) stops to work properly. Terminating the process and re-starting Visual Studio helps. If the problem persists between reboots however that probably isn't the cause.
Source-file-times (last modified) that are in the future can cause all kind of weird problems. To check file times, you can do a search for nothing (Windows XP) or "*" (Windows 7). That will list all files in the selected folder. Then sort the result by date to see the max/min file time. I have no idea where the incorrect file-times come from - I just know that it happens from time to time. Might be Visual Studio itself, might be some other tool I'm using.
You could try to start the application that uses your DLL from Visual Studio, with your DLL project already open. To do that, open the "Configuration Properties", select the "Debugging" page, and enter the .exe that should be started (+ arguments if you need any). Then start the debug session as you would for a .exe project.
A cure for many problems with Visual Studio is to "clean" the project manually, and do a full re-compile. Delete all files that are generated during a build process or that store solution or project "options". i.e. all .suo .ncb .user files plus everything in the "intermediate" and "output" folders. If you're using source control, just retrieve the whole project from your source control system into a clean directory, and re-build from scratch. (Getting everything "fresh" from source control also takes care of any potential file-time problems - at least with source control systems that don't preserve file-times)
Another possible reason would be, that VS loads the wrong .pdb file. A .pdb file with a matching name could be found in a symbol server/symbol directory configured for VS (or system wide through the _NT_SYMBOL_PATH variable), or in the VS symbol cache directory. How a .pdb file with a matching name came to be in such a place is a different story, but one can easily check if the wrong .pdb file is loaded: delete the .pdb file generated by the build, and start a debug session. If VS traces "symbols loaded" for the .exe/.dll in question, it must have found a .pdb file in some other location.
Sometimes VS seems to mess up breakpoint locations in some way. I don't exactly know when or how this happens, but one of the symptoms is, that if one deletes some breakpoints, they magically reappear when starting the next debug-session. I found that setting a new breakpoint, then deleting all break points by Debug/Delete All Breakpoints, and the re-setting the required ones helps.
1) Are you not able to hit the breakpoint at all ? Generally, it gets resolved once the code in the module or stack frame needs to be hit.
2) Check if your pdb is not source information stripped
Do a Build->Clean Solution, close visual studio and then restart it and do a fresh build. This happened to me once before, and that seemed to fix it, just some outdated pdb information, I suppose.
In my case, I had renamed the C++ project. The compiler was outputting newName.lib while my other projects were still referencing oldName.lib which of course would not be removed by a Build->Clean.
I found this out by following the advice to manually clean the build directory. The subsequent linker unresolved external reference gave away the situation.
In one Solution, I have two VC++ projects. Project A has linker inputs that are .obj files compiled by project B.
Visual Studio (2008) always tells me that project A is "out of date," and prompts me to ask if I want to rebuild it, every time I want to run/debug/build/etc. Even immediately after building the entire Solution: I do a successful full build, and then click Build again, and it wants to re-link Project A.
How can I prevent this from happening? Anyone understand what's going on here?
I think that the solution is to stop using .obj files from the other project. Instead, factor the code that is common to both A and B projects into own static library C and link both A and B to it.
I just had this problem with Visual Studio 2010 (both with and without SP1) and thanks to Ted Nugent I was able to fix it. The trick is to check whether all C++ header files listed in the project still exist, and remove the non-existing ones. Apparently this is a bug in the compiler.
Had something similar occur. I was working with code that used the system time and during the debug I was twiddling with it quite a lot. Somehow the files got some bad timestamps. In the build, it shows which files are getting recompiled, so I just opened each, forced a change (add space, delete a space) and then re-saved.
Similar to the old unix "touch".
In one project I had to do the same to its include files. But after 'touching' the files like that, the problem went away.