Skip to content

Added a message of enabled logs, and their paths.#13577

Open
AlesProkop wants to merge 8 commits intodotnet:mainfrom
AlesProkop:notify-file-names-of-logs
Open

Added a message of enabled logs, and their paths.#13577
AlesProkop wants to merge 8 commits intodotnet:mainfrom
AlesProkop:notify-file-names-of-logs

Conversation

@AlesProkop
Copy link
Copy Markdown
Member

@AlesProkop AlesProkop commented Apr 20, 2026

Fixes #12261

Context

There was no clear message in the logs when using either the /bl or the /fl flag that would indicate the location of the files that are being created by these logs. Also, there was no consistent way of telling which logs were enabled.

Changes Made

LoggingServiceLogMethods.cs

Added a method LogLoggersUsed(bool fileNames) which lists the names of all enabled logs in a diagnostic verbosity. Added new EventArgs which registers every enabled logger with information. This is then used for logging clickable links of paths that were created by loggers.

LoggerRegisteredEventArgs.cs

New EventArgs used for registering enabled loggers. It cointains infromation about the logger, such as the name of the logger, verbosity on which the logger operates on, file paths to files created by the logger and possible additional output file paths.

ParallelConsoleLogger.cs

Added handling of the LoggerRegisteredEventArgs.

TerminalLogger.cs

Added handling of the LoggerRegisteredEventArgs.

FileLogger.cs

Added a way to read the path to the file created by the filelogger, similarly to how binlog operates.

Testing

Added unit tests to LoggingServicesLogMethod_Tests.cs.

@AlesProkop
Copy link
Copy Markdown
Member Author

@dotnet-policy-service agree company="Microsoft"

Comment thread src/Build/BackEnd/Components/Logging/LoggingServiceLogMethods.cs Outdated
@AlesProkop AlesProkop marked this pull request as ready for review April 23, 2026 06:16
Copilot AI review requested due to automatic review settings April 23, 2026 06:16
Copy link
Copy Markdown
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR improves MSBuild’s user-facing logging by surfacing which loggers are enabled (e.g., /bl, /fl) and where their output files are being written, addressing confusion called out in #12261.

Changes:

  • Introduces LoggerRegisteredEventArgs to publish information about enabled loggers (name/verbosity/output paths).
  • Adds IFileOutputLogger and updates BinaryLogger/FileLogger to expose their output file paths.
  • Updates TerminalLogger/ParallelConsoleLogger to collect these events and print output paths at build end; adds new localized resource strings and unit tests.

Reviewed changes

Copilot reviewed 23 out of 23 changed files in this pull request and generated 14 comments.

Show a summary per file
File Description
src/Framework/LoggerRegisteredEventArgs.cs New Framework event args type used to report enabled logger details
src/Build/BackEnd/Components/Logging/LoggingServiceLogMethods.cs Emits “enabled logs” message + logger registration events during build start
src/Build/Logging/IFileOutputLogger.cs New internal interface for loggers that produce a primary output file
src/Build/Logging/FileLogger.cs Implements IFileOutputLogger to expose the log file path
src/Build/Logging/BinaryLogger/BinaryLogger.cs Implements IFileOutputLogger to expose the binlog path
src/Build/Logging/TerminalLogger/TerminalLogger.cs Captures logger-registration events and prints clickable paths in summary
src/Build/Logging/ParallelLogger/ParallelConsoleLogger.cs Captures logger-registration events and prints paths in summary
src/Build/Resources/Strings.resx Adds new resource strings for enabled logs / output file paths
src/Build/Resources/xlf/Strings.*.xlf Adds corresponding localization entries (state=new)
src/Build/Microsoft.Build.csproj Includes the new IFileOutputLogger.cs compile item
src/Build.UnitTests/BackEnd/LoggingServicesLogMethod_Tests.cs Adds unit tests for enabled log names and file path reporting

Comment thread src/Build/Logging/ParallelLogger/ParallelConsoleLogger.cs Outdated
Comment thread src/Build.UnitTests/BackEnd/LoggingServicesLogMethod_Tests.cs Outdated
Comment thread src/Build.UnitTests/BackEnd/LoggingServicesLogMethod_Tests.cs
Comment thread src/Build/Logging/ParallelLogger/ParallelConsoleLogger.cs Outdated
Comment thread src/Framework/LoggerRegisteredEventArgs.cs Outdated
Comment thread src/Build.UnitTests/BackEnd/LoggingServicesLogMethod_Tests.cs Outdated
Comment thread src/Build/Logging/TerminalLogger/TerminalLogger.cs Outdated
Comment thread src/Build/BackEnd/Components/Logging/LoggingServiceLogMethods.cs Outdated
Comment thread src/Framework/LoggerRegisteredEventArgs.cs Outdated
Comment thread src/Framework/LoggerRegisteredEventArgs.cs Outdated
Comment thread src/Build/BackEnd/Components/Logging/LoggingServiceLogMethods.cs Outdated
Comment thread src/Framework/LoggerRegisteredEventArgs.cs Outdated
? fileLogger.OutputFilePath
: null;

IReadOnlyList<string> additionalPaths = actualLogger is BinaryLogger bl
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you please explain the meaning of this AdditionalFilePaths? Can we maybe just add those to the OutputFilePath turning it to OutputFilePaths for all loggers?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A binary logger has this property so it can have multiple output paths. I am not sure if it is used but wanted to support it. I agree with your change, implemented it in the last commit.

Comment thread src/Build/BackEnd/Components/Logging/LoggingServiceLogMethods.cs Outdated
[Serializable]
public class LoggerRegisteredEventArgs : BuildMessageEventArgs
{
protected LoggerRegisteredEventArgs()
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do we need this constructor protected?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

After the changes, I changed it to internal. I think we do not want it public because an empty LoggerRegisteredEventArgs could be created which would be meaningless.

Comment thread src/Framework/LoggerRegisteredEventArgs.cs Outdated
/// </summary>
internal Dictionary<(int nodeId, int contextId), string> propertyOutputMap = new Dictionary<(int nodeId, int contextId), string>();

private readonly List<LoggerRegisteredEventArgs> _registeredLoggers = new List<LoggerRegisteredEventArgs>();
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: Prefer new() syntax per modern C# conventions

return;
}

if (e is LoggerRegisteredEventArgs loggerEvent)
Copy link
Copy Markdown
Member

@MichalPavlik MichalPavlik Apr 23, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The showOnlyErrors/showOnlyWarnings early returns before this capture, so under /clp:ErrorsOnly (or WarningsOnly) the loggers are never recorded and the summary silently omits the file-paths section.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should not be a problem anymore, since I changed the inheritance.

/// Arguments for the logger registered event, containing one or more logger registrations.
/// </summary>
[Serializable]
public sealed class LoggerRegisteredEventArgs : BuildMessageEventArgs
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As this event inherits from BuildMessageEventArgs, every third-party logger now receives it via MessageRaised (possibly with a null Message) and binlogs round-trip it lossily as a plain message. I think deriving from BuildStatusEventArgs (or at least guaranteeing a non null fallback message and bumping the binlog format) would be safer.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All right, thank you. Implemented that in the last commit.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Consider adding a message indicating binlog creation.

5 participants