Is there an existing issue for this?
Is your feature request related to a problem? Please describe the problem.
running a dotnet build on an ASP.NET Core project, does not indicate when Microsoft.Extensions.ApiDescription.Server runs the GetDocument tool. This is due to dotnet's new Terminal Logger, introduced in .NET 8.
Building with the new Terminal Logger disabled dotnet build --tl:off does show the logs from the tool invocation, including Generating document named 'v1'.
However, building with a Terminal Logger Verbosity flag set to detailed dotnet build -tlp:v=d does show the GetDocument logs.
Someone who is unaware these logs exist, will never be able to find them.
This can be an issue when debugging document generation.
Describe the solution you'd like
Surface these logs when using the new Terminal Logger, which is the default logger. This could be dependent on:
or may be resolved via: dotnet/msbuild#9810, by making the message higher priority, which may appear at lower log verbosity levels.
alternatively, -tlp:v=d may be an acceptable solution, and we could instead inform users about it in the README of the the NuGet package.
Additional context
No response
Is there an existing issue for this?
Is your feature request related to a problem? Please describe the problem.
running a
dotnet buildon an ASP.NET Core project, does not indicate whenMicrosoft.Extensions.ApiDescription.Serverruns theGetDocumenttool. This is due to dotnet's new Terminal Logger, introduced in .NET 8.Building with the new Terminal Logger disabled
dotnet build --tl:offdoes show the logs from the tool invocation, includingGenerating document named 'v1'.However, building with a Terminal Logger Verbosity flag set to detailed
dotnet build -tlp:v=ddoes show the GetDocument logs.Someone who is unaware these logs exist, will never be able to find them.
This can be an issue when debugging document generation.
Describe the solution you'd like
Surface these logs when using the new Terminal Logger, which is the default logger. This could be dependent on:
or may be resolved via: dotnet/msbuild#9810, by making the message higher priority, which may appear at lower log verbosity levels.
alternatively,
-tlp:v=dmay be an acceptable solution, and we could instead inform users about it in the README of the the NuGet package.Additional context
No response