I've got a project that VS10 constantly thinks is out of date. I can press [F7] and see the build finish without errors, only to wait a minute, press [F7] again and have it relink. If I try to run or debug, it warns me the project is out of date.
Based on the accepted answer here I was able to capture debug output from devenv.exe and isolate the reason it wants to rebuild:
[5392] Project 'Q:\swdev\X\tests\X.Y.Z\src\X.Y.Z.vcxproj' not up to date because 'Q:\SWDEV\X\TESTS\X.Y.Z\BIN\X64\WIN32\CHECKED\X.Y.Z.ILK' was modified at 08/15/2017 03:32:38, which is newer than 'Q:\SWDEV\X\TESTS\X.Y.Z\BIN\X64\WIN32\CHECKED\X.Y.Z.PDB' which was modified at 08/15/2017 07:32:36.
I'm not sure why the second time is shown in UTC and the first in local time, but I don't think that's the problem, because its claim of which is newer appears to correctly reflect the actual time relation.
When I check the files manually, the .ilk file is indeed modified at 3:32:38, 2 seconds later than the .pdb, modified at 3:32:36.
The answer to this question initially looked promising, but unlike in that problem, my CL and LINK settings do have separate PDB files, with C/C++ set to $(IntDir)vc$(PlatformToolsetVersion).pdb and Linker set to $(TargetDir)$(TargetName).pdb. Just to double-check, I also have a bin\x64\win32\checked\obj\vc100.pdb file modified 3:29:42.
I've seen suggestions in various places that 'always rebuilds' problems may be due to upgrading from a prior VS. That wasn't the case for this project (although it depends on a library that was upgraded from VS9 and which doesn't have this problem.) In fact, I have deleted everything but the source code and recreated the solution and project from scratch and the problem persists.
All my development files are on network shares exposed by Oracle Solaris' CIFS, but this server is also being used for many, many other things including projects in other versions of Visual Studio (9 and 12) without issue.
I'm confused as to why it is even configured to depend on the .ilk file. AFAIK that file would contain internal data the linker uses for incremental linking, so 1. you wouldn't expect it to meaningfully change unless actual linker inputs also change and 2. it is probably emitted around the same time as the .pdb, so I think it makes no sense to even test this file.
I don't know enough about the MSBuild system to know what is making it do this check or how to stop it.
As a workaround, I have turned off incremental linking, and that makes the problem go away, but I would really like to know if there is a proper solution. For this project, not using incremental linking is inconsequential, but for others it could become an issue.
