dotnet / dotnet/project-system

Give the developer tools to troubleshoot the Fast Up To Date heuristic misfires.

Open
#7,948 4 comments 2 reactions 1 assignee Claimed by @drewnoakes View on GitHub
Feature-Up-to-date Triage-Investigate
Dominant language
C#
Stars
1k
Forks
415
PR merge metrics
No merged PRs in 30d

Description

## Summary
The build inside Visual Studio IDE sometimes takes too much time, because projects are recompiled over and over again. However, developers do not know whether the projects are truly recompiled or it is the Fast Up To Date heuristic that fails to recognize that projects are up to date and submits them to msbuild every time. And we all know it takes eternity to msbuild to burn through all the targets necessary to determine that the project is up to date - that is the raison d'être for the heuristic in the first place.

There are 2 cases of heuristic misfires:

1. The project is up-to-date, but the heuristic fails to recognize it and submits the project to msbuild anyway.
- This one is possible to recognize if we build the project with diagnostics log level. This is because the first line is output by the heuristic and it often provides the reason why the build is necessary, like: **1>Project 'xyz' is not up to date. Input file 'abc' is modified after output file ''.** OR **1>Project 'xyz' is not up to date. Project item 'abc' has 'Copy to Output Directory' attribute set to 'Copy always'.**. This is extremely helpful.
1. The project is NOT up-to-date, but the heuristic fails to recognize it and does NOT submit the project to msbuild.
- There is no diagnostics for this case at all.
- It has more potential for producing incorrect build results.

The current situation where the only output from the heuristic is during the diagnostic build is problematic. Indeed, we care about the heuristic only for big solutions, but building a big solution at the diagnostic log level is not feasible - it makes the output pane explode with gazillion lines of output when all we need is just the first line for every project being built.

It would be very useful to decouple the build output from the heuristic diagnostic messages. Like having a dedicated heuristic output pane or better still being able to configure it to write to a file, so that invoking devenv build from the command line could also produce the heuristic diagnostics.

An ideal solution would be to have a command line devenv flag to provide the heuristic log file path AND have the dedicated output pane.

Another part of the troubleshooting is being able to produce binary logs from the builds that get submitted to msbuild. It is very important, since it lets us confirm that the project is indeed up-to-date or not. Unfortunately, the super useful Project System Tools extension is effectively broken for VS 2022 - the binary log it produces lacks crucial information.

## User Impact
In our organisation we have hundreds of developers working on a couple of big solutions. When projects are rebuilt without a seemingly good reason our time is wasted. And when there is no easy way to troubleshoot these rebuilds devs either give up or depend on someone who knows all these details and there are very few people with this level of such specific knowledge in our organisation. I assume our situation is typical.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.