[Breaking change]: dotnet watch logs internal-facing messages to stderr instead of stdout #48628
Description
Description
Starting in .NET 10 RC2, dotnet watch will emit its own log messages to the stderr channel instead of stdout. This is part of a general trend towards dotnet CLI commands not 'obscuring' the stdout channel, which is often reserved/assumed to have special semantics when running certain kinds of applications, like LSP or MCP servers. This change was implemented in dotnet/sdk#50820.
Version
.NET 10 RC 2
Previous behavior
dotnet watch would emit log messages to stdout
New behavior
dotnet watch would emit log messages to stdout
Type of breaking change
- Binary incompatible: Existing binaries might encounter a breaking change in behavior, such as failure to load or execute, and if so, require recompilation.
- Source incompatible: When recompiled using the new SDK or component or to target the new runtime, existing source code might require source changes to compile successfully.
- Behavioral change: Existing binaries might behave differently at run time.
Reason for change
This is part of a general trend towards dotnet CLI commands not 'obscuring' the stdout channel, which is often reserved/assumed to have special semantics when running certain kinds of applications, like LSP or MCP servers. This change was implemented in dotnet/sdk#50820. In general we want the CLI to 'get out of the way' of your applications.
Recommended action
Most users shouldn't need to take any action. If you do need the dotnet watch messages on stdout, you can redirect the stderr stream to stdout - for example 2>&1 (redirecting the 2 file descriptor for stderr to the 1 file descriptor for stdin).
Feature area
SDK
Affected APIs
No response