Building E2ETests.csproj in VS is very slow

[SteveSandersonMS]

One of our ASP.NET team-level goals when working within this repo is being able to run a single test on a code change in the inner loop in less than 1 minute. We can't currently satisfy this goal for any E2E test because E2ETests.csproj itself takes over a minute to build (on my laptop at least), and that doesn't include building whatever chain of runtime projects the developer is modifying. Note that I'm talking about VS builds here - it's significantly faster on the CLI.

By collecting a binary build log, I see that E2ETests.csproj spends the vast majority of its time inside _GetProjectReferenceTargetFrameworkProperties. This is part of the .NET Core SDK and has the following role:

<!--
    ====================================================================================
                                        _GetProjectReferenceTargetFrameworkProperties

    Builds the GetTargetFrameworks target of all existent project references to get a list
    of all supported TargetFrameworks of the referenced projects. Calls the
    GetReferenceNearestTargetFrameworkTask to determine the closest match for each project.
    This allows a cross-targeting project to select how it should be configured to build
    against the most appropriate target for the referring target framework.

    ======================================================================================
  -->

The log viewer also shows that this is calling a task GetTargetFrameworks on the whole transitive closure of referenced projects, and there apppear to be 102 of those.

I don't know whether the SDK team would expect _GetProjectReferenceTargetFrameworkProperties to complete faster than this or not. It seems like either we're hitting an unusually bad case for it, or it just doesn't scale well. We should expect customer projects to contain > 100 transitive dependencies - that's not unusual at all.

Alternatively perhaps the problem is within ASP.NET Core's project graph, or some other thing we're customizing during the build. It's also unclear why the perf is only this bad in VS, and not for CLI builds.

[dougbu]

Thoughts @wli3 and @dsplaisted❔ See the following from the description in particular

I don't know whether the SDK team would expect _GetProjectReferenceTargetFrameworkProperties to complete faster

[dougbu]

Including this in the DoI project for discussion in that context

[wli3]

It is a pretty old change dotnet/msbuild#1018 . @dsplaisted do you have the context?

[dsplaisted]

@cdmihai @nkolev92 Is this something that static graph would help with? Is it expected that the GetTargetFrameworks target would be called on all transitive references if most of the build is up-to-date (perhaps only in VS)?

[cdmihai]

Surprised that _GetProjectReferenceTargetFrameworkProperties is calling the whole transitive closure. My untested assumption is that it's because in the new style sdk a project is made to explicitly depend on its entire closure. If the assumption holds, it means that if you set DisableTransitiveProjectReferences to true, you'll most likely fix your perf issue. The consequence to that is that you might need to add more ProjectReference declarations in your projects to explicitly declare your project dependencies.

-graph usually helps because it takes advantage of the entire potential parallelism that the project dependency graph exposes (because it builds the graph bottom up instead of top down). The branchier the graph, the more parallelism it exposes.

[SteveSandersonMS]

Thanks for the feedback, everyone.

I just re-tried this on VS 16.8.1 (with .NET Core 5.0.100) and it's no longer reproing for me. The build of E2ETests.csproj is now the same speed in VS as it is on the commandline, or in some cases faster because of the fast-up-to-date check.

It doesn't clarify what was going on before, but something in the build toolchain or our repo build config has apparently changed and resolved this. I'll close it now since it doesn't seem like there's any other investigation/action that would make sense to take.