Generalize "Primary output(s)" detection for TerminalLogger

[rainersigwald]

Currently, TL scans through high-priority messages looking for -> to determine what the "primary output" of a given project is in order to render the "project succeeded" message with the path of and a link to that output.

msbuild/src/MSBuild/TerminalLogger/TerminalLogger.cs

Lines 554 to 556 in 69a76bb

	// Detect project output path by matching high-importance messages against the "$(MSBuildProjectName) -> ..."
	// pattern used by the CopyFilesToOutputDirectory target.
	int index = message.IndexOf(FilePathPattern, StringComparison.Ordinal);

This is clunky and a structured approach would be cleaner. In addition, the currently-logged message isn't always the "right" output, and it'd be nice if it was more customizable by individual projects (see also #8370 (comment)).

I can think of a couple of ways to do this:

1. augment ProjectFinishedEventArgs to have an optional list of critical outputs, derived from an item that can be manipulated during the build.
2. Create a new special target to return that and special-case that target's TargetFinished event in the logger.

The former is more complex and we'd have to be mindful of the perf cost of the item lookup at project-finished time, but it's more flexible in the case of multiple invocations of the same project instance (for instance, build and publish the same project in separate invocations). A target would get single-instanced.

[baronfel]

@rainersigwald silly thought - should we try to use the Outputs from the directly-requested Task(s)? Is that good enough? What would that look like for existing commonly-requested targets?

• Build
• Pack
• Publish
• Test/VSTest

[rainersigwald]

Not silly at all. Right now that would require:

1. Listen to ProjectStartedEventArgs for TargetNames
2. Listen to TargetFinishedEventArgs for those specific TargetNames
3. Look at TargetOutputs for the targets we care about

We'd have to filter the lists from 1 because in normal execution there are different calls to a project with different entry points ("get list of TFs"/build/"get random other outputs") only some of which are really relevant to the user.

[baronfel]

Current requests for this include

• @javiercn for the JS project system
• @nohwnd for test outputs
• NuGet for package outputs

[nohwnd]

Our usage here would be for run attachments, such as TRX, code coverage or process dumps. There can be 0, 1 or multiple files per project.

[baronfel]

Another use case for this might be the Quickbuild cache plugin - when that triggers projects don't appear like they are built at all. with this feature the plugin could report the cached results on behalf of the projects that were not actually built.

[baronfel]

We should consider special-casing output detection for Pack for .NET 9 as well. When packaging, a message like the following is emitted:

Successfully created package 'E:\Code\FsAutoComplete\src\FsAutoComplete\bin\Release\fsautocomplete.0.74.0.nupkg'.

(NOTE: this message will be localized). In addition, the GenerateNuspec Target has outputs in the form of the NuGetPackOutput Item type:

If the target to build for a project was Pack and NuGetPackOutput is available, we could use that to get a structured view of the package to treat as the output.

The logged Message doesn't provide a Code so we can't look for it structurally: https://github.com/NuGet/NuGet.Client/blob/f929a0f74b92c3593521a4556d41d6f96528fb24/src/NuGet.Core/NuGet.Commands/CommandRunners/PackCommandRunner.cs#L202C37-L204