Document breaking change: 'dotnet watch' logs to stderr instead of stdout in .NET 10 RC 2

[Copilot]

This PR documents a breaking change in .NET 10 RC 2 where dotnet watch now emits its internal log messages to stderr instead of stdout.

Changes

• Created new breaking change document at docs/core/compatibility/sdk/10.0/dotnet-watch-stderr.md
• Added entry to the table of contents (docs/core/compatibility/toc.yml)
• Added entry to the .NET 10 breaking changes index (docs/core/compatibility/10.0.md)

Breaking Change Summary

Starting in .NET 10 RC 2, dotnet watch emits its own log messages to the stderr channel instead of stdout. This change is part of a broader effort to prevent .NET CLI commands from obscuring the stdout channel, which is often reserved for special semantics when running applications like LSP or MCP servers.

Most users won't need to take any action. If users need the dotnet watch messages on stdout, they can redirect the stderr stream using 2>&1.

This change was implemented in dotnet/sdk#50820.

Fixes #45871

Original prompt

---

This section details on the original issue you should resolve

<issue_title>[Breaking change]: dotnet watch logs internal-facing messages to stderr instead of stdout</issue_title>
<issue_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

---

Associated WorkItem - 494514</issue_description>

Comments on the Issue (you are @copilot in this section)

Fixes #48628

---

💬 Share your feedback on Copilot coding agent for the chance to win a $200 gift card! Click here to start the survey.