Summary
We should define an enablement mechanism for Terminal Logger in the .NET SDK to allow for easily enabling/disabling the logger.
Background and Motivation
The mechanism should
- respect any explicit TerminalLogger setting the user has provided
- let user-provided CLI arguments for managing TerminalLogger take precedence over any automatically-supplied arguments
- be able to handle the various ways that MSBuild arguments are automatically injected into a build (specifically Directory.Build.rsp)
Proposed Feature
Based on these requirements, we think the SDK enablement should
- Check the MSBUILDTERMINALLOGGER environment variable, and if no user value for this variable has been set a default value should be applied
- For the 8.0 SDK cycle, the default value of
off should be used by the SDK
- For the 9.0 SDK, the default value of
auto should be used by the SDK
In addition, usage telemetry for the TerminalLogger feature should be emitted from the SDK to help gauge usage of the feature and validate the decision to turn it on by default. The telemetry should report:
- the normalized user-set value (if any)
- the value the SDK used (which should match the user-set value in all cases)
- if TerminalLogger was valid to be used
This will help us detect cases where the user explicitly disable Terminal Logger when it would otherwise have been used - this is the value we'd like to minimize
Alternative Designs
Another take on the design would be to check the same variables/precedence, but inject the Terminal Logger arguments via CLI arguments. However, due to the precedence of MSBuild's response file handling, if a user disabled Terminal Logger via a response file the response file's arguments would be overridden by the arguments explicitly set by the SDK.
Finally, we could also not pass through anything and set new defaults in MSBuild itself. We decided against this because we infer that the MSBuild.exe user base is less likely to use the feature, and the SDk user base is more likely to use the feature. It's also harder to collect usage telemetry for MSBuild.exe, so we would have a more difficult time justifying the feature's usage.
Summary
We should define an enablement mechanism for Terminal Logger in the .NET SDK to allow for easily enabling/disabling the logger.
Background and Motivation
The mechanism should
Proposed Feature
Based on these requirements, we think the SDK enablement should
offshould be used by the SDKautoshould be used by the SDKIn addition, usage telemetry for the TerminalLogger feature should be emitted from the SDK to help gauge usage of the feature and validate the decision to turn it on by default. The telemetry should report:
This will help us detect cases where the user explicitly disable Terminal Logger when it would otherwise have been used - this is the value we'd like to minimize
Alternative Designs
Another take on the design would be to check the same variables/precedence, but inject the Terminal Logger arguments via CLI arguments. However, due to the precedence of MSBuild's response file handling, if a user disabled Terminal Logger via a response file the response file's arguments would be overridden by the arguments explicitly set by the SDK.
Finally, we could also not pass through anything and set new defaults in MSBuild itself. We decided against this because we infer that the MSBuild.exe user base is less likely to use the feature, and the SDk user base is more likely to use the feature. It's also harder to collect usage telemetry for MSBuild.exe, so we would have a more difficult time justifying the feature's usage.