Support a non script based entrypoint

• This issue is blocking
• This issue is causing unreasonable pain

Following up on https://github.com/dotnet/aspnetcore/pull/21017#issuecomment-621915214.

Current state

Currently a repository build runs through these stages: build.cmd|sh --> eng/common/build.cmd|sh -> Arcade’s Build.proj -> Tools.proj, ProjectToBuild items, Sign.proj, Publish.proj.

To get into more details, Arcade’s Build.proj is current responsible for

• Upfront restore: Invoking the restore target on Tools.proj and on the ProjectToBuild items.
• Build the ProjectToBuild items (either a Solution File or msbuild project files)
• Sign
• Publish

With the current design, Arcade’s Build.proj file invokes the Restore and Build target on every passed in project which has multiple caveats:

1. For every ProjectToBuild restore, NuGet is invoked. As a side note, in an internal thread it was discussed that the more often NuGet is invoked, the more likely the cross-org authentication plugin fails.
2. Using the newly added NuGet static graph restore feature works best (and fastest) with a single restore entry point.
3. Declaring dependencies between passed in ProjectToBuild items is difficult as you can either define BuildInParallel on all of them or on none.
4. dotnet CLI verbs like dotnet build and dotnet restore don’t work on the repo root level.

dotnet/runtime

In dotnet/runtime we recently removed passing all our ProjectToBuild items to Arcade and instead added a root repo Build.proj entrypoint file which uses Microsoft.Build.Traversal which is then invoked by Arcade’s Build.proj file.

• https://github.com/dotnet/runtime/blob/master/Build.proj#L1-L12
• https://github.com/dotnet/runtime/blob/master/eng/Build.props

We additionally allow filtering on the Build.proj’s ProjectReferences based on the /p:Subset property.

In addition to the Build.proj entry point file, we have repo local SDK acquisition scripts in the repository root which bootstrap the dotnet SDK (via the Arcade scripts) and invoke it.

https://github.com/dotnet/runtime/blob/master/dotnet.cmd https://github.com/dotnet/runtime/blob/master/dotnet.sh

That combination allows us to run dotnet restore, dotnet build and dotnet test from the repository root. The caveat here is that Arcade’s Tools.proj, Sign.proj and Publish.proj files aren’t sequenced in if the repository’s Build.proj file is invoked directly.

Proposal

My ask is that we support an entrypoint in Arcade which avoids Arcade’s eng/common/build.cmd/sh and Build.proj files completely. This could be achieved via

• a props/targets file import or
• an auto detection feature in the Arcade SDK to add props/targets/ProjectReferences to the entry point project.
• possible 99+ other solutions 😀

cc @markwilkie @tmat @dougbu @jeffkl @danmosemsft @ericstj

Recently Triaged Issues

All issues in this section should be triaged by the v-team into one of their business objectives or features.

[tmat]

We are now able to build Roslyn.sln in dev and PR validation (without producing VSIX) using dotnet build: https://github.com/dotnet/roslyn/pull/45589

[markwilkie]

This is a lot of disruptive work that will likely have a significant bug tail. Having said that, I do see how it could benefit dev workflow and thus am making it into an epic to contrast/compare with other dev workflow stuff…