Skip to content
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
32 changes: 32 additions & 0 deletions documentation/data-collection-systems.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,32 @@
# MSBuild data-collection systems

MSBuild has three main logging and feedback systems, with different characteristics and audiences. This is an overview focused on the purposes of the systems as relevant to developers of MSBuild.

## MSBuild loggers

Loggers are the primary user-facing way to understand what MSBuild is doing. It's possible to write a custom logger, but most people use the [built-in ones](Logging-behavior.md):

* `TerminalLogger` for interactive console use in .NET SDK,
* `BinaryLogger` for detailed capture and analysis,
* `ConsoleLogger`, the default MSBuild output when redirected and in `MSBuild.exe`, and
* `FileLogger`, the longstanding “more detailed than console” text output.

Mechanically, loggers receive logging events and note their details, serializing them in their entirety in the case of the binlog and ignoring or textualizing them for the other primary loggers.

New `*EventArgs` classes should carry most of their information via their _structure_, for easier analysis. Many older events render their information to a string that can be difficult to parse.

Logs can be and often are analyzed post-build. Interesting use cases are
Comment thread
rainersigwald marked this conversation as resolved.

* The Visual Studio Code or GitHub Actions “problem matcher” regexes that take text output of the build and present it as “build errors”.
* The [Structured Log Viewer](https://msbuildlog.com) application (for interactive analysis).
* Tools built on top of the binlog APIs.

## Tracing events

MSBuild also emits [trace events](specs/event-source.md). These are structured events (ETW on Windows) that can be captured via runtime configuration outside of MSBuild. They contain less information than a full binlog, but have lower performance impact to enable.

These events are captured by default in Visual Studio performance infrastructure, including “Speedometer” and “Perf DDRIT” tests and Visual Studio Feedback when users “record a trace” of the problem. They can also be manually collected and analyzed in PerfView.
Comment thread
rainersigwald marked this conversation as resolved.
Comment thread
rainersigwald marked this conversation as resolved.

## Telemetry

MSBuild can also be configured to send [telemetry](VS-Telemetry-Data.md) through the Visual Studio and .NET SDK channels. This allows getting aggregate data from a variety of users, but we have to consider data volume and privacy.
Loading