Add support for new output path format

[dsplaisted]

Add support for simplified output paths and RootOutputPath property.

Based on this design spec: dotnet/designs#281. The design doc needs to be updated. The main changes from the current version:

• Switching away from the "artifacts" name, and putting the new output paths under bin instead. This is discussed in this comment
• The new output path format is not enabled by default on .NET 8 and higher. You have to opt in to it. This is due to some of the issues in the previously referenced comment, as well as concerns about builds (especially Maui builds) running into Windows path length issues.

I needed a name for a property that would enable the new output paths. I went with UseStandardOutputPaths, which was the best I could think of. Better name suggestions are welcome.

The property that puts all output for a solution under a single folder is RootOutputPath, which I think is a reasonably good name. Still open to suggestions though.

[dotnet-issue-labeler]

I couldn't figure out the best area label to add to this PR. If you have write-permissions please help me learn by adding exactly one area label.

[dsplaisted]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[nagilson]

Thank you for wrangling up all of those tests... wow that was a lot of hard-coded paths.

It looks like there are still a lot of test failures, including a few of the newer tests, so I won't look at the MSBuild code and try it out until those are fixed. Also hoping to get a little more engagement on the design spec

UseStandardOutputPaths seems like it has a similar-ish problem in what is "standard" might change... (I am thinking of netstandard rids.)
Some brainstormed ideas:
UseSimplifiedOutputPaths
UseExperimentalOutputPaths

I like RootOutputPath. Maybe also: FlatOutputPath?

[baronfel]

Very excited to see this land for previews and user feedback!

Re: the name of the opt-in property, I agree with @nagilson that Standard's meaning can change over time, but I don't have a compelling alternative. Maybe UseUnifiedOutputPaths? This is something we can potentially update across previews.

[baronfel]

Do you think this is a gap in the layering that we should try to change for .NET 8? I see a few lines below that you suggest this - I think it would be worth doing for a later preview!

[Nirmal4G]

Why not BuildDir?

My proposals:

1. Introduce BuildDir as a top-level directory for all things build
2. Fix output path customization limitations

I personally think we should start from existing paths and modify it to cover all the goals presented in the new proposal. I'm not good at explaining things over words, so I could create a PR on both MSBuild repo and here to explain the changes better!

[joeloff]

For the Standard naming issue, I'll toss another suggestion out, Legacy

[richlander]

Can you add an example to your initial comment what default and opt-in will look like? That would help a lot.

[dsplaisted]

@joeloff @nagilson @baronfel @rainersigwald I've updated the implementation here to (I believe) match the latest version of the design proposal.

I still need to update tests and probably add some more test coverage, but the implementation is ready to review, I believe.

[marcpopMSFT]

@dsplaisted fyi, we had a bad branch creation for preview 3 so we deleted it and repushed with the right commit. I had to close and reopen your PR during that activity (and fixed a merge conflict)

[rainersigwald]

I didn't look at all the tests, but have a few small comments on the MSBuild logic.

[rainersigwald]

If you stick with .artifacts I think you should add it to the .gitignore template

sdk/template_feed/Microsoft.DotNet.Common.ItemTemplates/content/Gitignore/.gitignore

Line 19 in 09d8fec

# Build results

[rainersigwald]

Could we error in that case instead? I don't like the idea of accidentally diverging the implementation over time.

[dsplaisted]

So ArtifactsPath just wouldn't be allowed in the project file at all?

We go through some hoops to make BaseIntermediateOutputPath work whether it's set in the project file or beforehand. If it's set in the project file then it doesn't affect MSBuildProjectExtensionsPath. This seemed analogous.

I just had a crazy idea: Maybe we could de-duplicate some of the logic by having a .props file that's conditionally imported in two different places depending on where ArtifactsPath is defined?

[nagilson]

Doesn't sound crazy to me, sounds pretty smart 😄

[dsplaisted]

Might be totally unrelated, but does this potentially impact things like the build configuration dialogs in Visual Studio? What happens when a user launches VS directly/from a console that don't have the properties set for using a single output path or is the assumption that they're either specified as environment variables or defined in a directory.build.props?

@joeloff I think the main scenario is to put it in Directory.Build.props or to specify it on the command-line. If ArtifactsPath is specified in Directory.Build.props then Visual Studio should respect it. Do you mean the Configuration Manager dialog? It doesn't look like that shows output paths so I don't think it would be affected at all.

If you only specify the artifacts path on the command-line, then Visual Studio would build using the default (old) paths. The different output paths shouldn't interfere with each other though (the test that verifies that you can switch between output path formats helps verify that). Also, I think specifying the artifacts path on the command line may be more of a CI scenario so it isn't as likely to happen together with Visual Studio.

[dsplaisted]

Followup items:

• Port changes to main branch
• Add .artifacts to Visual Studio default .gitignore file. 1 2
• De-duplicate default output path logic depending on whether ArtifactsPath is defined in project file or beforehand
• Add hook to MSBuild to inject targets after Directory.Build.props import, and use that in SDK instead of duplicate import logic.
• Consider adding telemetry data point to detect when artifacts output path is turned on

[nagilson]

It would also be good to de-duplicate the code for TestSolution and the new test library code for solutions.