Document breaking change: ToolCommandName no longer set for non-tool packages (#50274)

Author: Copilot

docs/core/compatibility/10.0.md

@@ -144,6 +144,7 @@ If you're migrating an app to .NET 10, the breaking changes listed here might af
 | [HTTP warnings promoted to errors in `dotnet package list` and `dotnet package search`](sdk/10.0/http-warnings-to-errors.md) | Behavioral/source incompatible change |
 | [NUGET_ENABLE_ENHANCED_HTTP_RETRY environment variable removed](sdk/10.0/nuget-enhanced-http-retry-removed.md) | Behavioral change |
 | [NuGet logs an error for invalid package IDs](sdk/10.0/nuget-packageid-validation.md) | Behavioral change |
+| [`ToolCommandName` not set for non-tool packages](sdk/10.0/toolcommandname-not-set.md) | Source incompatible |
 
 ## Serialization
 

docs/core/compatibility/sdk/10.0/toolcommandname-not-set.md

@@ -0,0 +1,54 @@
+---
+title: "Breaking change - ToolCommandName is not set for non tool packages"
+description: "Learn about the breaking change in .NET 10 where ToolCommandName is only set for projects with PackAsTool set to true."
+ms.date: 12/02/2025
+ai-usage: ai-assisted
+---
+
+# `ToolCommandName` not set for non-tool packages
+
+The `ToolCommandName` property is no longer set automatically for all projects during build or package operations. It's now only set when `PackAsTool` is set to `true`, indicating that the project is a .NET tool package.
+
+## Version introduced
+
+.NET 10
+
+## Previous behavior
+
+Previously, the `ToolCommandName` property was always set during build or pack operations, regardless of whether the project was configured as a tool package.
+
+## New behavior
+
+Starting in .NET 10, the `ToolCommandName` property is only set when `PackAsTool` is set to `true`, indicating that the project is a .NET tool.
+
+## Type of breaking change
+
+This change can affect [source compatibility](../../categories.md#source-compatibility).
+
+## Reason for change
+
+The `ToolCommandName` property doesn't make sense for non-tool projects. Setting it for all projects was unnecessary and could cause confusion about the project's purpose.
+
+## Recommended action
+
+If your project relies on the `ToolCommandName` property being set, you have two options:
+
+- Set the property explicitly in your project file:
+
+  ```xml
+  <PropertyGroup>
+    <ToolCommandName>your-command-name</ToolCommandName>
+  </PropertyGroup>
+  ```
+
+- Convert your project to a .NET tool by setting `PackAsTool` to `true`:
+
+  ```xml
+  <PropertyGroup>
+    <PackAsTool>true</PackAsTool>
+  </PropertyGroup>
+  ```
+
+## Affected APIs
+
+None.

docs/core/compatibility/toc.yml

@@ -176,6 +176,8 @@ items:
                 href: sdk/10.0/nu1015-packagereference-version.md
               - name: PrunePackageReference privatizes direct prunable references
                 href: sdk/10.0/prune-packagereference-privateassets.md
+              - name: "'ToolCommandName' not set for non-tool packages"
+                href: sdk/10.0/toolcommandname-not-set.md
           - name: Serialization
             items:
               - name: System.Text.Json checks for property name conflicts