Visual Studio Rebuilds unmodified projects

Question

So, as the title reads, I have a VS2010 solution with ~50 projects in it right now. If I make a change to a \"top level\" project that nothing references then VS still rebui

Answer 1

Based on your observations, it sounds like you have projects expressing dependencies to other projects in a way that isn't obvious. It is possible for orphaned dependencies to remain in project files without being apparent in the UI. Have you looked through a misbehaving project file after opening it in a text editor? Checked solution build dependencies?

If you're not able to spot anything, try recreating one of your projects from scratch to see if the new project exhibits the same problem. If the clean project builds correctly, you'll know that you have unwanted dependencies expressed somewhere. As far as I know, these would have to be in the project file(s) or the solution file, unless you have makefiles or other unusual build steps.

Answer 2

I had the same issues with you. I found that it came from some deleted files. When I had removed the files from my project, the issues was gone. Regards.

Answer 3

I had the problem of Visual Studio rebuilding projects when upgrading from Visual Studio 2015 to 2017 and I add this answer for the benefit of those who might experience similar problems, as it does not seem to be documented anywhere.

In my case, the problem was that all projects in the solution had the same intermediate Output path (obj). The file GeneratedInternalTypeHelper.cs gets generated by all projects containing XAML. Up to Visual Studio 2015, the build process apparently did not check for the file date of this file and thus no problem with it occurred. With VS2017 the file date of this file is checked and because a later project in the build process will overwrite it (with the same content), the earlier project will re-build, re-triggering the later build, ad infinitum.

The solution in this case is to ensure that all projects have differing intermediate output directories, which will make the problem go away.

Answer 4

For .Net Core Projects, all solutions above are not working. I've found the solution. In case you are using Visual Studio 2019:

1. Build the solution twice
2. Turn on Tools -> Options -> Projects and Solutions -> SDK-Style Projects -> Logging Level -> Verbose
3. Clear the output window
4. Build your start project
5. Inspect the output window. All the string starting with FastUpToDate
6. You will find some project items that are making your project not up to date.
7. Fix these issues and try again from step 1. If your fixes are correct, you will achieve Build: 0 succeeded, 0 failed, {n} up-to-date, 0 skipped in the last string of build output.

Answer 5

I had this same problem and it turned out to be related to a couple of project that had a copy local reference to a dll in their own output directory.

The key to finding this was having diagnostic output set for the build output, but also knowing what to look for in the log. Searching for: 'not up to date' was the key.

Answer 6

For this category of build problems setting MSBuild output verbosity to 'diagnostic' is indeed a necessary first step. Most of the time the stated reason for the re-builds would be enough to act upon, 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.