.NET 9 SDK prints relative path for build artifacts (UX)

[tmds]

With previous versions of the SDK, the SDK printed an absolute path:

  console2 -> /tmp/console2/bin/Debug/net8.0/console2.dll

The .NET 9 SDK is printing a relative path:

  console succeeded (2.3s) → bin/Debug/net9.0/console.dll

With the new format, it is no longer possible to copy the path and use it as-is.

Version:

$ dotnet --version
9.0.100-preview.2.24105.1

cc @baronfel

[tmds]

Encountering another issue: it seems dotnet pack doesn't mention the path to the NuGet package that gets built. The package is not mentioned at all.

$ dotnet pack
MSBuild version 17.10.0-preview-24076-03+0d8d09e5c for .NET
Restore complete (0.4s)
You are using a preview version of .NET. See: https://aka.ms/dotnet-support-policy
  lib succeeded (0.4s) → bin/Release/net9.0/lib.dll

Build succeeded in 1.0s

[tmds]

This also reproduces on a .NET 8 SDK when passing the --tl option.

cc @rainersigwald

Note: without the --tl argument, the NuGet package gets mentioned on the first pack. For successive pack commands it does not get mentioned when the package doesn't need to be rebuilt.

[KalleOlaviNiemitalo]

If the behaviour is going to be configurable, then the GenerateFullPaths property that is passed to the Csc task might be usable for this as well.

[tmds]

This is what happens when I run dotnet test with the .NET 9 preview 1 SDK:

$ dotnet test
Restore complete (0.5s)
You are using a preview version of .NET. See: https://aka.ms/dotnet-support-policy
  xunit_project succeeded (2.5s) → bin/Debug/net9.0/xunit_project.dll

Build succeeded in 4.1s

It mentions nothing about the tests being executed and all of them passing.

[KalleOlaviNiemitalo]

Live logger explicitly converts the path to relative here: https://github.com/dotnet/msbuild/blob/299e0514835a1588e6ef21b1da748462dec706b8/src/MSBuild/TerminalLogger/TerminalLogger.cs#L453-L465

[baronfel]

The relative path thing is by design - we got a lot of user feedback that schedule paths cleared the display.

The poor test output is also known - the test team is contributing a much better display that we hope to do in preview 2.

[tmds]

The relative path thing is by design - we got a lot of user feedback that schedule paths cleared the display.

Personally, my preference is the longer absolute path, because I can copy it elsewhere and it will just work.

The poor test output is also known

@baronfel did you also see my comment about dotnet pack not printing out the nuget package path: #38552 (comment). Is it also a known issue?

[baronfel]

Yes, the MSBuild repo has a tracking issue for making the 'primary output' of a build (the thing that's shown on the right hand side of the static build summary for each project) configurable. Right now it's tied to the primary output DLL of a project, but packages are a sensible thing to link as well.

[baronfel]

Linking some items in the MSBuild repo for tracking purposes:

• dotnet test output
• 'primary output' customization
• customize primary output to use absolute paths

[baronfel]

@tmds if we're tracking all of your requests, should we close this?

[tmds]

Yes, let's close this one.