At work I am currently working with a large project in Visual Studio. Yesterday before going home I used Windows's Task Manager to forcibly close Visual Studio while it was either in the middle of building, or in the middle of cancelling a build.
(Details: I set VS to do a rebuild of the project before leaving my desk for the day, but after starting the rebuild I noticed that one of the programs that is part of the solution was still running. I know from experience with this project that this will cause build errors as VS will not be able to overwrite the executable, and indeed I saw the errors indicating that this had happened scroll by in the output pane. I therefore selected to cancel the rebuild, and closed the program, intending to start the rebuild over again once the program had closed. However, after 5 minutes VS still had not finished cancelling the build - the "Cancel" option was still selectable and the other options on the Build menu were still greyed out. I wanted to leave for the day and didn't want to have to do a rebuild when I came back in the morning, so I tried to close VS. It would not close because it was in the middle of a build, so I opened Task Manager and End Tasked it. Then I opened VS again, opened the solution, and started a rebuild. There were no problems that were apparent at that time.)
Today, I find that any time I try to debug the project, VS complains that the project is out of date and asks if I want to build it. This happens even if I have only just built. I followed the instructions given in answers to this question that specify changing the build output verbosity level and then searching the output for "not up to date". There are indeed files listed with this message, but the thing is, these aren't new files, nor have they newly been messed around with. Before the forced close yesterday, VS was not complaining about these files (or at least, it wasn't treating them as grounds to complain that the project is out of date), and now it is, though nothing has changed about the files in the meantime.
For some reason Visual Studio has decided to be more fussy about these files than it was before. Now maybe it would be a good idea to go through these files and see whether the "copy to output directory" configuration option ought to be changed, but the more immediate issue is that this is stopping me from working effectively and it would be nice to set VS's behaviour back to what it was before.
