So I have a problem facing VS code changes.
Whatever changes I have applied to my solution and built, it is working fine and I can see those changes being applied when I debug. But the same changes aren't applying to the .exe file.
I have tried release build as well, Same with that. It Debugs the release build fine but doesn't apply those changes to the .exe file.
It Debugs the release build fine but doesn't apply those changes to
.exe file.
When you debug the project, VS debug engine will try to fetch the output project.exe and project.pdb for debugging. So if the debugging works well(those changes being applied), the output project.exe should also work without any issues(changes applied).
See this(for C++, similar situation with C#, VB):
This error message comes when VS debug engine can't find the output .exe, that's why I say if the changes are applied during debugging, it actually indicates the changes have been applied to your .exe file.
Let me name the project which outputs the .exe ProjectA, other projects in your solution are B,C,D. Here are two directions you can check:
If the code changes you mean is in Project A:
Right click project A in Solution Explorer=>Properties, check the value of your Output Directory(C++) or Output path in build tab(C#), it represents where the output .exe will actually exist, and VS debug engine will fetch the .exe in this path.
So make sure you tested the .exe in this path instead of old versions from other locations.
If the code changes you mean is in B,C,D, and A depends on B,C,D:
In most of the time VS will help copy the assemblies from B,C,D into A's bin folder, but I'm not sure if something's wrong with your environment which breaks this. You should make sure all the assemblies in your bin folder are updated.
I think this issue comes from your project instead of IDE(create a new simple project to check if the issue occurs in it). And in which way did you check if the changes are applied? Make sure you use the same way no matter checking during debugging or checking the .exe.
Updated:
According to Sandesh, this issue could be resolved by a clean(clean
old versions completely) rebuild.
Right click your project and click property, in General page, set "Enable Managed Incremental Build" as "Yes". It will replace the old exe file after every builds.
In a team project I'm working on, setting a breakpoint in a file (say IdeasController.cs) will lead to erratic debugger behaviour if there's another file with the same name in the solution. I've reproduced the problem on several developers' workstations.
Example
I set a breakpoint in IdeasController.cs in our Web API:
Another file called IdeasController.cs exists in our separate MVC 4 web project. In the screenshot below, the debugger shows the Api->IdeasController source code, but the line highlight matches the code structure of Web->IdeasController. The breakpoint is duplicated, with one of them in the middle of a comment block.
The Breakpoint window shows the breakpoint in both files simultaneously:
On some workstations the debugger steps through the correct lines (regardless of the line highlight); on others it cheerfully steps through irrelevant lines (including comments and whitespace). I'm guessing this depends on which source file it chooses to display.
What I've tried
I've trawled the Internet. This kind of problem seems to occur when there's a mismatch between the debug file (*.pdb), the source file, and the compiled code. There are a lot of possible causes: duplicate file names (which can confuse the debugger[5]), outdated project build files, invalid solution cache, or incorrect build configuration.
These are the solutions I've found and tried:
Checked my build configuration.
Made sure the project isn't built in release mode.
Made sure we don't have code optimization enabled.
Made sure the project's debug module was loaded correctly. (Started debugging the project and checked Debug > Windows > Modules. Both assemblies are listed, not optimized, and have a symbol status of "Symbols loaded".)
Reset the debugging metadata & Visual Studio cache.
Closed Visual Studio and deleted the solution cache file (*.suo).[1]
Deleted each project's build output (the bin and obj folders). (For future reference: open the solution folder in Windows Explorer and type this in the search box: "type:folder AND (name:=bin OR name:=obj)".
Deleted the assembly cache folder (C:\Documents and Settings\<user>\Local Settings\Application Data\dl3).[2][3]
None of these had any effect. I can rename one of the files (without renaming the class) to temporarily work around the problem, but that's far from ideal.
Where I am now
Page 14 of my latest Google search. Suggestions would be much appreciated. :)
If no better alternatives exist, you could put the breakpoint in code:
System.Diagnostics.Debugger.Break();
Just don't forget to remove it afterwards...
I'm so glad I found this post, thought I was the only one and was going insane! I'm having the same problem in VS2012 with VB.Net and have tried everything the OP mentioned.
Unique naming of the files seems to be the only 100% fix that I've found. Disabling all breakpoints until the application has loaded and then re-enabling the breakpoints you need works most of the time. Breakpoints in Lambda functions can still give you issues.
I just had the exact same problem. What solved it for me was deleting the .suo files belonging to the solution that contained the affected project/source file.
I also deleted my local symbolcache but I don't think that had anything to do with it.
(My solution contains multiple projects, one file (DataAdapter.cs) in one project was affected by this (VisualStudio put my breakpoints in the pdb belonging to System.Data.DataAdapter). I opened the .csproj file directly and was able to correctly set the breakpoint.)
I had the same problem today. I was able to trace it back to the fact that I had forgotten to set the platform target to x86 while debugging. Unfortunately the others (x64 / Any CPU) can be problematic while debugging. At least VS 2008 doesn't like them. I guess this is yet another reason to stay away.
Some speculation... I think the debugger (while running a 64 bit app) somehow "steals" breakpoints away from a file in certain cases. For me it was because another assembly was loaded first which had the same file name. I was able to avoid the issue, even in 64 bit mode, if I first manually loaded the assembly with my breakpoints: Assembly.Load("MyAssemblyWithBreakpoints");
Hope this (my first stackoverflow contribution) helps.
Although renaming one of the files will work, I found that the simplest solution is to temporarily disable automatic loading of symbols for the "other" assembly.
Start the debugger and continue until you hit the erroneous breakpoint.
Find where the debugger actually set the breakpoint using the Call Stack window:
Right-click on the row with the yellow arrow and enable Show Module Names. (The row should also have the red breakpoint symbol on it.)
The assembly name is now visible on that row.
Find that assembly in the Modules window (Debug > Windows > Modules).
Right-click on the assembly and disable Always Load Automatically.
Stop the debugger.
Start debugging again.
By doing this, you're preventing the Visual Studio debugger from mapping the breakpoint to the wrong assembly. It will then load the symbols from the other [presumably] correct assembly first, therefore mapping the breakpoint to the correct assembly.
Why does this happen?
This seems to occur when two different symbol files (PDB files) — for two different assemblies — both reference a source file with the same name. Although the source files are completely different, the Visual Studio debuggger seems to get confused.
For example, imagine there are two different files both with the name IdeasController.cs. The first one compiles into assembly Api.dll, and the second one compiles into assembly Web.dll.
When the debugger loads symbols, it will either load Api.pdb or Web.pdb first. Let's say it loads Api.pdb first. Then even if you set a breakpoint in Web\IdeasController.cs, it will find a match for IdeasController.cs in Api.pdb. It then maps code from Web\IdeasController.cs to Api.dll. This won't map correctly, of course, and so you see all sorts of odd issues while debugging.
I just had this issue on Visual Studio 2017 (Version 15.9.7), were break points were skipped and the debugger just "jumped" over return statements etc.
After a while I noticed, that I've recently added a .runsettings file to the project - and it turned out, that in my case configuring the CodeCoverage data collector is causing this problem.
As soon as I removed this section:
<DataCollector friendlyName="Code Coverage" uri="datacollector://Microsoft/CodeCoverage/2.0" assemblyQualifiedName="Microsoft.VisualStudio.Coverage.DynamicCoverageDataCollector, Microsoft.VisualStudio.TraceCollector, Version=11.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"> ... </DataCollector>
from the .runsettings file, it worked like a charm again.
I just backed up and deleted the file and then added back to the project, that solved the problem. I just whish i did it before going through the beforementioned list :)
You may also try to Clean and Rebuild (not Build) all projects.
I was hitting this issue in Visual Studio 2015.
I had a sub-folder with a DLL I wanted to save as Version1. It seems even after removing the reference to that DLL, and then adding a reference to another project studio pulled in the existing reference and went to the wrong source file. I removed that DLL in the sub-folder then Studio got the correct source.
I found a helpful link on [MSDN that shows how to clear prior associated source files in studio at this link][1].
Summary:
In the Solution Explorer, right click on the solution name (ex: Solution ‘TestApplication’) and select Properties This will bring up the Solution Property Pages dialog
Under Common Properties, select Debug Source Files
In the Search these paths for source code files (Visual Studio .NET 2003) / Directories containing source code (Visual Studio 2005) box, add, remove and/or reorder the directories as desired
Click the OK button
I was having the same issue. In my case both the projects had same port numbers. I was able to resolve it by changing the port number of the project whose file's breakpoints were not hitting.
My guess is that IIS Express was caching the pdb file from the second project since both files had the same name, and the projects had the same port number.
What worked for me (VS2017) was disabling this option in Tools --> Options... --> Debugging --> General: "Require sources files to exactly match the original version", which is enabled by default but I had it turned on.
That was not enough though, I also had to manually remove obj and bin folders for all projects in solution.
Delete all the .pdb files of the project where the break point is hitting wrongly. This will solve the issue.
It happened to me (in VS 2008) to have two child breakpoint with the same memory address and the same associated file.
Those breakpoints were spawned at a certain time during the running of the process.
I noticed that I had duplicated .dll files in my project folders, and resolved removing the duplicated .dll, while keeping only one .dll per name in the debugging folder structure. (As example in my case I had /bin/Example.dll and /bin/Plug-in/Example.dll both present under my debug folder structure).
I had a very similar problem. In my case the problem was a different target .net framework in one of the projects causing VS2017 to wrongly load a source file (with the same name) of another project, not the one being activated with
ObjectHandle handle = Activator.CreateInstance
Changing the project's target framework to be the same in all projects fixed it.
I had a similar issue with the breakpoint being set in another file with the same filename in a different project.
It was caused by the fact that the debugging was started for that other project, while it was not started for the project where I tried to set the breakpoint. The breakpoint creation worked correctly after doing the Debug > Start New Instance for the intended project.
I have a very similar problem as described here.
I also upgraded a mixed solution of C++/CLI and C# projects from Visual Studio 2008 to Visual Studio 2010. And now in Visual Studio 2010 one C++/CLI project always runs out of date.
Even if it has been compiled and linked just before and F5 is hit, the messagebox "The project is out of date. Would you like to build it?" appears. This is very annoying because the DLL file is very low-tiered and forces almost all projects of the solution to rebuild.
My pdb settings are set to the default value (suggested solution of this problem).
Is it possible the get the reason why Visual Studio 2010 forces a rebuild or thinks a project is up to date?
Any other ideas why Visual Studio 2010 behaves like that?
For Visual Studio/Express 2010 only. See other (easier) answers for VS2012, VS2013, etc
To find the missing file(s), use info from the article Enable C++ project system logging to enable debug logging in Visual Studio and let it just tell you what's causing the rebuild:
Open the devenv.exe.config file (found in %ProgramFiles%\Microsoft Visual Studio 10.0\Common7\IDE\ or in %ProgramFiles(x86)%\Microsoft Visual Studio 10.0\Common7\IDE\). For Express versions the config file is named V*Express.exe.config.
Add the following after the </configSections> line:
<system.diagnostics>
<switches>
<add name="CPS" value="4" />
</switches>
</system.diagnostics>
Restart Visual Studio
Open up DbgView and make sure it's capturing debug output
Try to debug (hit F5 in Visual Studio)
Search the debug log for any lines of the form:
devenv.exe Information: 0 : Project 'Bla\Bla\Dummy.vcxproj' not up to date because build input 'Bla\Bla\SomeFile.h' is missing.
(I just hit Ctrl+F and searched for not up to date) These will be the references causing the project to be perpetually "out of date".
To correct this, either remove any references to the missing files from your project, or update the references to indicate their actual locations.
Note: If using 2012 or later then the snippet should be:
<system.diagnostics>
<switches>
<add name="CPS" value="Verbose" />
</switches>
</system.diagnostics>
In Visual Studio 2012 I was able to achieve the same result easier than in the accepted solution.
I changed the option in menu Tools → Options → Projects and Solutions → Build and Run → *MSBuild project build output verbosity" from Minimal to Diagnostic.
Then in the build output I found the same lines by searching for "not up to date":
Project 'blabla' is not up to date. Project item 'c:\foo\bar.xml' has 'Copy to Output Directory' attribute set to 'Copy always'.
This happened to me today. I was able to track down the cause: The project included a header file which no longer existed on disk.
Removing the file from the project solved the problem.
We also ran into this issue and found out how to resolve it.
The issue was as stated above "The file no longer exists on the disk."
This is not quite correct. The file does exist on the disk, but the .VCPROJ file is referencing the file somewhere else.
You can 'discover' this by going to the "include file view" and clicking on each include file in turn until you find the one that Visual Studio can not find. You then ADD that file (as an existing item) and delete the reference that can not be found and everything is OK.
A valid question is: How can Visual Studio even build if it does not know where the include files are?
We think the .vcproj file has some relative path to the offending file somewhere that it does not show in the Visual Studio GUI, and this accounts for why the project will actually build even though the tree-view of the includes is incorrect.
The accepted answer helped me on the right path to figuring out how to solve this problem for the screwed up project I had to start working with. However, I had to deal with a very large number of bad include headers. With the verbose debug output, removing one caused the IDE to freeze for 30 seconds while outputting debug spew, which made the process go very slowly.
I got impatient and wrote a quick-and-dirty Python script to check the (Visual Studio 2010) project files for me and output all the missing files at once, along with the filters they're located in. You can find it as a Gist here: https://gist.github.com/antiuniverse/3825678 (or this fork that supports relative paths)
Example:
D:\...> check_inc.py sdk/src/game/client/swarm_sdk_client.vcxproj
[Header Files]:
fx_cs_blood.h (cstrike\fx_cs_blood.h)
hud_radar.h (cstrike\hud_radar.h)
[Game Shared Header Files]:
basecsgrenade_projectile.h (..\shared\cstrike\basecsgrenade_projectile.h)
fx_cs_shared.h (..\shared\cstrike\fx_cs_shared.h)
weapon_flashbang.h (..\shared\cstrike\weapon_flashbang.h)
weapon_hegrenade.h (..\shared\cstrike\weapon_hegrenade.h)
weapon_ifmsteadycam.h (..\shared\weapon_ifmsteadycam.h)
[Source Files\Swarm\GameUI - Embedded\Base GameUI\Headers]:
basepaenl.h (swarm\gameui\basepaenl.h)
...
Source code:
#!/c/Python32/python.exe
import sys
import os
import os.path
import xml.etree.ElementTree as ET
ns = '{http://schemas.microsoft.com/developer/msbuild/2003}'
#Works with relative path also
projectFileName = sys.argv[1]
if not os.path.isabs(projectFileName):
projectFileName = os.path.join(os.getcwd(), projectFileName)
filterTree = ET.parse(projectFileName+".filters")
filterRoot = filterTree.getroot()
filterDict = dict()
missingDict = dict()
for inc in filterRoot.iter(ns+'ClInclude'):
incFileRel = inc.get('Include')
incFilter = inc.find(ns+'Filter')
if incFileRel != None and incFilter != None:
filterDict[incFileRel] = incFilter.text
if incFilter.text not in missingDict:
missingDict[incFilter.text] = []
projTree = ET.parse(projectFileName)
projRoot = projTree.getroot()
for inc in projRoot.iter(ns+'ClInclude'):
incFileRel = inc.get('Include')
if incFileRel != None:
incFile = os.path.abspath(os.path.join(os.path.dirname(projectFileName), incFileRel))
if not os.path.exists(incFile):
missingDict[filterDict[incFileRel]].append(incFileRel)
for (missingGroup, missingList) in missingDict.items():
if len(missingList) > 0:
print("["+missingGroup+"]:")
for missing in missingList:
print(" " + os.path.basename(missing) + " (" + missing + ")")
I've deleted a cpp and some header files from the solution (and from the disk) but still had the problem.
Thing is, every file the compiler uses goes in a *.tlog file in your temp directory.
When you remove a file, this *.tlog file is not updated. That's the file used by incremental builds to check if your project is up to date.
Either edit this .tlog file manually or clean your project and rebuild.
I had a similar problem, but in my case there were no files missing, there was an error in how the pdb output file was defined: I forgot the suffix .pdb (I found out with the debug logging trick).
To solve the problem I changed, in the vxproj file, the following line:
<ProgramDataBaseFileName>MyName</ProgramDataBaseFileName>
to
<ProgramDataBaseFileName>MyName.pdb</ProgramDataBaseFileName>
I had this problem in VS2013 (Update 5) and there can be two reasons for that, both of which you can find by enabling "Detailed" build output under "Tools"->"Projects and Solutions"->"Build and Run".
"Forcing recompile of all source files due to missing PDB "..."
This happens when you disable debug information output in your compiler options (Under Project settings: „C/C++“->“Debug Information Format“ to „None“ and „Linker“->“Generate Debug Info“ to „No“: ). If you have left „C/C++“->“Program Database File Name“ at the default (which is „$(IntDir)vc$(PlatformToolsetVersion).pdb“), VS will not find the file due to a bug (https://connect.microsoft.com/VisualStudio/feedback/details/833494/project-with-debug-information-disabled-always-rebuilds).
To fix it, simply clear the file name to "" (empty field).
"Forcing rebuild of all source files due to a change in the command line since the last build."
This seems to be a known VS bug too (https://connect.microsoft.com/VisualStudio/feedback/details/833943/forcing-rebuild-of-all-source-files-due-to-a-change-in-the-command-line-since-the-last-build) and seems to be fixed in newer versions (but not VS2013). I known of no workaround, but if you do, by all means, post it here.
I don't know if anyone else has this same problem, but my project's properties had "Configuration Properties" -> C/C++ -> "Debug Information Format" set to "None", and when I switched it back to the default "Program Database (/Zi)", that stopped the project from recompiling every time.
Another simple solution referenced by Visual Studio Forum.
Changing configuration: menu Tools → Options → Projects and Solutions → VC++ Project Settings → Solution Explorer Mode to Show all files.
Then you can see all files in Solution Explorer.
Find the files marked by the yellow icon and remove them from the project.
It's OK.
Visual Studio 2013 -- "Forcing recompile of all source files due to missing PDB". I turned on detailed build output to locate the issue: I enabled "Detailed" build output under "Tools" → "Projects and Solutions" → "Build and Run".
I had several projects, all C++, I set the option for under project settings: (C/C++ → Debug Information Format) to Program Database (/Zi) for the problem project. However, this did not stop the problem for that project. The problem came from one of the other C++ projects in the solution.
I set all C++ projects to "Program Database (/Zi)". This fixed the problem.
Again, the project reporting the problem was not the problem project. Try setting all projects to "Program Database (/Zi)" to fix the problem.
I met this problem today, however it was a bit different. I had a CUDA DLL project in my solution. Compiling in a clean solution was OK, but otherwise it failed and the compiler always treated the CUDA DLL project as not up to date.
I tried the solution from this post.
But there is no missing header file in my solution. Then I found out the reason in my case.
I have changed the project's Intermediate Directory before, although it didn't cause trouble. And now when I changed the CUDA DLL Project's Intermediate Directory back to $(Configuration)\, everything works right again.
I guess there is some minor problem between CUDA Build Customization and non-default Intermediate Directory.
I had similar problem and followed the above instructions (the accepted answer) to locate the missing files, but not without scratching my head. Here is my summary of what I did. To be accurate these are not missing files since they are not required by the project to build (at least in my case), but they are references to files that don't exist on disk which are not really required.
Here is my story:
Under Windows 7 the file is located at %ProgramFiles(x86)%\Microsoft Visual Studio 10.0\Common7\IDE\%. There are two similar files devenv.exe.config.config and devenv.exe.config. You want to change later one.
Under Windows 7, you don't have permission to edit this file being in program files. Just copy it somewhere else (desktop) change it and than copy it back to the program files location.
I was trying to figure out how to connect DebugView to the IDE to see the missing files. Well, you don't have to do anything. Just run it, and it will capture all the messages. Make sure Capture Events menu option is selected in Capture menu which by default should be selected.
DebugView will NOT display all the missing files at once (at least it didn't for me)! You would have DebugView running and than run the project in Visual Studio 2010. It will prompt the project out of date message, select Yes to build and DebugView will show the first file that is missing or causing the rebuild. Open the project file (not solution file) in Notepad and search for that file and delete it. You are better off closing your project and reopening it again while doing this delete. Repeat this process until DebugView no longer shows any files missing.
It's kind of helpful to set the message filter to not up to date from the DebugView toolbar button or Edit → Filter/Highlight option. That way the only messages it displays are the one that has `not up to date' string in it.
I had lots of files that were unnecessary references and removing them all fixed the issue following the above steps.
Second way to find all the missing files at once
There is a second way to find these files all at once, but it involves (a) source control and (b) integration of it with Visual Studio 2010. Using Visual Studio 2010, add your project to a desired location or dummy location in source control. It will try to add all the files, including those that don't exist on disk as well but referenced in the project file. Go to your source control software like Perforce, and it should mark these files which don't exist on disk in a different color scheme. Perforce shows them with a black lock on them. These are your missing references. Now you have a list of them all, and you can delete all of them from your project file using Notepad and your project would not complain about being out of date.
For me it was the presence of a non-existing header file on "Header Files" inside the project. After removing this entry (right-click > Exclude from Project) first time recompiled, then directly
========== Build: 0 succeeded, 0 failed, 5 up-to-date, 0 skipped ==========
and no attempt of rebuilding without modification was done. I think is a check-before-build implemented by VS2010 (not sure if documented, could be) which triggers the "AlwaysCreate" flag.
If you are using the command-line MSBuild command (not the Visual Studio IDE), for example if you are targetting AppVeyor or you just prefer the command line, you can add this option to your MSBuild command line:
/fileLoggerParameters:LogFile=MyLog.log;Append;Verbosity=diagnostic;Encoding=UTF-8
As documented here (warning: usual MSDN verbosity). When the build finishes, search for the string will be compiled in the log file created during the build, MyLog.log.
I'm using Visual Studio 2013 Professional with Update 4 but didn't find resolution with any of the other suggestions, however, I did manage to resolve the issue for my Team project.
Here's what I did to cause the problem -
Created a new class object (Project -> Add Class)
Renamed the file via Solution Explorer and clicked yes when asked if I wanted to automatically rename all references to match
Here's what I did to solve the problem -
Go to Team Explorer Home
Click Source Control Explorer
Drill into the folder where all of the class/project files are
Found the ORIGINAL filename in the list and deleted it via right-click
Build
If this is the case for you then just be extra sure that you're deleting the phantom file rather than the actual one you want to keep in the project.
I had this problem and found this:
http://curlybrace.blogspot.com/2005/11/visual-c-project-continually-out-of.html
Visual C++ Project continually out-of-date (winwlm.h macwin32.h rpcerr.h macname1.h missing)
Problem:
In Visual C++ .Net 2003, one of my projects always claimed to be out of date, even though nothing had changed and no errors had been reported in the last build.
Opening the BuildLog.htm file for the corresponding project showed a list of PRJ0041 errors for these files, none of which appear on my system anywhere:
winwlm.h macwin32.h rpcerr.h macname1.h
Each error looks something like this:
MyApplication : warning PRJ0041 : Cannot find missing dependency 'macwin32.h' for file 'MyApplication.rc'.
Your project may still build, but may continue to appear out of date until this file is found.
Solution:
Include afxres.h instead of resource.h inside the project's .rc file.
The project's .rc file contained "#include resource.h". Since the resource compiler does not honor preprocessor #ifdef blocks, it will tear through and try to find include files it should be ignoring. Windows.h contains many such blocks. Including afxres.h instead fixed the PRJ0041 warnings and eliminated the "Project is out-of-date" error dialog.
In my case one of the projects contains multiple IDL files. The MIDL compiler generates a DLL data file called 'dlldata.c' for each of them, regardless of the IDL file name. This caused Visual Studio to compile the IDL files on every build, even without changes to any of the IDL files.
The workaround is to configure a unique output file for each IDL file (the MIDL compiler always generates such a file, even if the /dlldata switch is omitted):
Right-click the IDL file
Select Properties - MIDL - Output
Enter a unique file name for the DllData File property
I spent many hours spent tearing out my hair over this. The build output wasn't consistent; different projects would be "not up to date" for different reasons from one build to the next consecutive build.
I eventually found that the culprit was DropBox (3.0.4). I junction my source folder from ...\DropBox into my projects folder (not sure if this is the reason), but DropBox somehow "touches" files during a build. Paused syncing and everything is consistently up-to-date.
There are quite a few potential reasons and - as noted - you need to first diagnose them by setting MSBuild verbosity to 'Diagnostic'. Most of the time the stated reason would be self explanatory and you'd be able to act on it immediatelly, BUT occasionally MSBuild would erroneously claim that some files are modified and need to be copied.
If that is the case, you'd need to either disable NTFS tunneling or duplicate your output folder to a new location. Here it is in more words.
This happened to me multiple times and then went away, before I could figure out why. In my case it was:
Wrong system time in the dual boot setup!
Turns out, my dual boot with Ubuntu was the root cause!! I've been too lazy to fix up Ubuntu to stop messing with my hardware clock. When I log into Ubuntu, the time jumps 5 hours forward.
Out of bad luck, I built the project once, with the wrong system time, then corrected the time. As a result, all the build files had wrong timestamps, and VS would think they are all out of date and would rebuild the project.
Most build systems use data time stamps to determine when rebuilds should happen - the date/time stamp of any output files is checked against the last modified time of the dependencies - if any of the dependencies are fresher, then the target is rebuilt.
This can cause problems if any of the dependencies somehow get an invalid data time stamp as it's difficult for the time stamp of any build output to ever exceed the timestamp of a file supposedly created in the future :P
For me, the problem arose in a WPF project where some files had their 'Build Action' property set to 'Resource' and their 'Copy to Output Directory' set to 'Copy if newer'. The solution seemed to be to change the 'Copy to Output Directory' property to 'Do not copy'.
msbuild knows not to copy 'Resource' files to the output - but still triggers a build if they're not there. Maybe that could be considered a bug?
It's hugely helpful with the answers here hinting how to get msbuild to spill the beans on why it keeps building everything!
If you change the Debugging Command arguments for the project, this will also trigger the project needs to be rebuilt message. Even though the target itself is not affected by the Debugging arguments, the project properties have changed. If you do rebuild though, the message should disappear.
I had a similar issue with Visual Studio 2005, and my solution consisted of five projects in the following dependency (first built at top):
Video_Codec depends on nothing
Generic_Graphics depends on Video_Codec
SpecificAPI_Graphics depends on Generic_Graphics
Engine depends on Specific_Graphics
Application depends on Engine.
I was finding that the Video_Codec project wanted a full build even after a full clean then rebuild of the solution.
I fixed this by ensuring the pdb output file of both the C/C++ and linker matched the location used by the other working projects. I also switched RTTI on.
Another one on Visual Studio 2015 SP3, but I have encountered a similar issue on Visual Studio 2013 a few years back.
My issue was that somehow a wrong cpp file was used for precompiled headers (so I had two cpp files that created the precompiled headers). Now why did Visual Studio change the flags on the wrong cpp to 'create precompiled headers' without my request I have no clue, but it did happen... maybe some plugin or something???
Anyway, the wrong cpp file includes the version.h file which is changed on every build. So Visual Studio rebuilds all headers and because of that the whole project.
Well, now it's back to normal behavior.
I had a VC++ project that was always compiling all files and had been previously upgraded from VS2005 to VS2010 (by other people). I found that all cpp files in the project except StdAfx.cpp were set to Create (/Yc) the precompiled header. I changed this so that only StdAfx.cpp was set to create the precompiled header and the rest were set to Use (/Yu) the precompiled header and this fixed the problem for me.
I'm on Visual Studio 2013 and just updated to the Windows 10 May 2019 update and compiling suddenly had to be redone every time, regardless of changes. Tried renaming the pch to ProjectName instead of TargetName, looked for missing files with the detailed log and that Python script, but in the end it was my time was not synced with MS's servers (by like milliseconds).
What resolved this for me was
"Adjust date and time" in the control panel
"Sync Now"
Now my projects don't need to be recompiled for no reason.
I think that you placed some newline or other whitespace. Remove it and press F5 again.
The .NET projects are always recompiled regardless. Part of this is to keep the IDE up to date (such as IntelliSense). I remember asking this question on an Microsoft forum years ago, and this was the answer I was given.
When I right-click my solution in the Solution Explorer and choose Properties I get a dialog where I can select the Startup Project.
I sometimes select Current selection (If it is an experimental solution with lots of projects I jump between), but most often it is a Single startup project selected, which would usually be the main WinForms applications or or Console application.
My problem is that whenever I do a treeclean with the tfpt command (Team Foundation Power Tools 2008) this setting is forgotten. So when I try to run my solution the next time, it has defaulted to some random project and I get an error stating that I cannot run a class library or something like that. Which is obvious of course. But where is this setting stored? Why is it forgotten when I do the treeclean? The solution file is still there, right? Isn't solution properties stored there?
Reference 1
Arian Kulp says:
I was struggling with trying to figure
out why a certain solution of mine
wasn’t starting right. It was in VB
with four projects. Upon initial open
it would set a certain project with a
DLL output as startup. If I set the
EXE as startup project, it was fine,
but when I distribute code I always
clean it by removing *.suo and *.user
files, and bin/obj folders. Upon
opening the “cleaned” version, it
would always revert to the DLL project
and fail to F5 nicely. The fix turned
out to be simple, though I’m curious
as to why I needed to do this at all.
In the solution file, there are a list
of pseudo-XML “Project” entries. It
turns out that whatever is the first
one ends up as the Startup Project,
unless it’s overridden in the suo
file. Argh. I just rearranged the
order in the file and it’s good.
I’m guessing that C# is the same way
but I didn’t test it. I hope that
this helps someone!
Reference 2
Setting the StartUp Project
Which project is the "startup" project only has any relevance for debugging, which means it's user metadata from the point of the solution and the projects. Regardless of which project is the "startup" project, the compiled code is the same.
Because of this, the information is stored as a user setting in the Solution User Options file (solution.suo) which accompanies the Solution file (solution.sln). The .suo file "Records all of the options that you might associate with your solution so that each time you open it, it includes customizations that you have made" according to MSDN.
The .suo file is a binary file. If you want to read or change it programatically, you have to use IVsPersistSolutionOpts.LoadUserOptions from the Microsoft.VisualStudio.Shell.Interop namespace.
I suspect that this setting is saved as part of the .suo file created whenever you edit a solution file. This file contains various user settings, such as breakpoints, watch data etc.
I cannot confirm this but that would be my guess.
Unfortunately its not XML its a binary file and not easily edited.
I just wrote a little command line utility for windows called slnStartupProject to solve this. It sets the Startup Project automatically like this:
slnStartupProject slnFilename projectName
I personally use it to set the project after generating the solution with cmake that always sets a dummy ALL_BUILD project as the first project in the solution.
The source is on github:
https://github.com/michaKFromParis/slnStartupProject
Forks and feedbacks are welcome.
Hope this helps!