[Breaking change]: `dotnet watch` logs internal-facing messages to stderr instead of stdout

[baronfel]

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