Traversal projects don't work with the Visual Studio Fast Up-to-date Check

[drewnoakes]

VS's fast up-to-date check (FUTDC) performs a quick file timestamp check on a projects inputs and outputs to determine whether it needs to call MSBuild. When it can avoid doing so, builds are much faster.

However, this requires having both inputs and outputs to compare against.

Normally, building a project twice should make the second build a no-op. For a traversal project, the project will eternally be considered out-of-date.

Logging shows:

Output 'D:\repo\MyTraversalProject\Debug\net472\MyTraversalProject.dll' does not exist, not up-to-date.

This problem might be addressed by having the build for this project produce a dummy file in the intermediate (obj) folder, and referencing that file as a UpToDateCheckOutput item. On every build, touch that file.

It'll also have to stop listing the non-existent output file as an expected output.

For more info on this, see https://github.com/dotnet/project-system/blob/main/docs/up-to-date-check.md.

[jeffkl]

@drewnoakes I don't think Traversal projects should ever load in Visual Studio as they're just used to make it so you can create a project in a directory and then "build" that directory which is really just a dispatch to projects under that directory. Traversal projects are supposed to be a replacement for solution files and then to load actual projects in Visual Studio, we recommend users run SlnGen to generate a solution file on-the-fly. Are you seeing a use case for loading Traversal projects in Visual Studio?

[jasonmalinowski]

How common is it for traversal projects to be loaded where the projects it traverses to to not be loaded? Because if all the actual target projects are loaded, could the traversal project always be considered up-to-date since each targeted project will also have it's own fast-up-to-date check?

[drewnoakes]

@jeffkl this came up in the Roslyn repo. See #594.

[drewnoakes]

could the traversal project always be considered up-to-date

There's not currently a feature that enables that in the FUTDC. We have DisableFastUpToDateCheck which causes MSBuild to always be called, but there's no inverse option that causes MSBuild to never be called.

[jeffkl]

Okay catching up on the Teams thread, I don't think IntegrationTestBuildProject.csproj should be using Traversal and instead should be using NoTargets. Traversal should just be a simple dirs.proj with <ProjectReferences /> and never loads in Visual Studio. NoTargets is for a project that should load in VS but doesn't emit a binary. Since NoTargets makes no assumptions about output though, each project needs to tell FUTD about its outputs. #148