Document .NET 11 CLI improvements

[Copilot]

Documents .NET 11 CLI additions missing from command references and clarifies NuGet subcommand help behavior.

• Project references

  • Add dotnet reference add --file syntax and guidance for file-based apps.

• Formatting

  • Add dotnet format --framework syntax and multi-targeting guidance.

• Tool execution

  • Add dotnet tool exec --yes syntax, confirmation behavior, and trust guidance.

• Solution filters

  • Add support for solution filters (*.slnf* files) in dotnet sln, including new instructions for creating, adding, listing, and removing projects from solution filters. Updated all relevant sections to mention solution filters and clarified option descriptions.

• dotnet new install --prelease

  • Add the --prerelease option to dotnet new install to allow selection of the latest prerelease template package version. Updated synopsis and description accordingly.

dotnet reference add --file app.cs ../Library/Library.csproj
dotnet format --framework net11.0
dotnet tool exec --yes dotnetsay

• Fixes Document new CLI options #55891

---

Internal previews

File	Preview link
docs/core/tools/dotnet-format.md	Learn preview
docs/core/tools/dotnet-new-install.md	Learn preview
docs/core/tools/dotnet-reference-add.md	Learn preview
docs/core/tools/dotnet-sln.md	Learn preview
docs/core/tools/dotnet-tool-exec.md	Learn preview

Build report

[Copilot]

Copilot wasn't able to review any files in this pull request.

---

💡 Add a code-review agent skill for context-aware, tailored reviews. Learn more in the docs.

[Copilot]

🟡 Changes recommended

Several unresolved documentation inaccuracies must be corrected before approval.

Get a fresh assessment by requesting another Copilot review.

Review details

Suppressed comments (8)

docs/core/tools/dotnet-format.md:63

• --framework is mutually exclusive with the existing --folder option for dotnet format whitespace; the CLI rejects that combination. Because this new description explains framework selection but omits the restriction, users can follow the page and get an error. Document the incompatibility.

  Specifies the target framework moniker (TFM), such as `net11.0`, to format in a multi-targeted project. If you don't specify this option, `dotnet format` formats all target frameworks. Available starting with .NET 11.

docs/core/tools/dotnet-format.md:21

• The SDK registers --framework with -f as an alias, but the synopsis omits the short form. Include -f| so the command syntax matches the actual CLI and users can discover the supported shorthand.

  [--framework <FRAMEWORK>] [--include <INCLUDE>] [--include-generated]

docs/core/tools/dotnet-reference-add.md:66

• --file and --project are mutually exclusive; the CLI fails if both are supplied. The new synopsis lists both options as independently optional, and the option text doesn't state the restriction, so document it to avoid invalid combinations.

  Specifies the file-based app to add project references to. For example, specify `app.cs` to add `#:project` directives to a file-based app. Available starting with .NET 11.

docs/core/tools/dotnet-reference-add.md:66

• The new file mode has different behavior and option validity than project mode: it writes #:project directives, and --framework is rejected for file-based apps. The article's description still says the command only adds <ProjectReference> elements, while this option text doesn't state the restriction, so users can follow the synopsis into a guaranteed error. Update both descriptions.

- **`--file <FILE>`**

  Specifies the file-based app to add project references to. For example, specify `app.cs` to add `#:project` directives to a file-based app. Available starting with .NET 11.

docs/core/tools/dotnet-sln.md:175

• Name-based removal isn't supported for .slnf files: filter removal matches the stored relative project path and doesn't perform the name-without-extension lookup described below. This new wording now promises PROJECT_NAME support for filters; restrict that argument to solution files or document the filter limitation.

  The path to, or name of, the project or projects to remove from the solution or solution filter. Unix/Linux shell [globbing pattern](https://en.wikipedia.org/wiki/Glob_(programming)) expansions are processed correctly by the `dotnet sln` command.

docs/core/tools/dotnet-sln.md:120

• The add subsection description at line 107 still says “solution file,” so the new .slnf support is omitted from the command summary. Update the summary to mention solution filters as well.

  The solution file (*.sln* or *.slnx* file) or solution filter (*.slnf* file) to use.

docs/core/tools/dotnet-sln.md:167

• The remove subsection description at line 154 still says “solution file,” so the new .slnf support is omitted from the command summary. Update the summary to mention solution filters as well.

  The solution file (*.sln* or *.slnx* file) or solution filter (*.slnf* file) to use.

docs/core/tools/dotnet-sln.md:58

• The slnf template creates a filter that references a parent .sln or .slnx; it doesn't create that parent solution, and projects added to a filter must already exist in the parent. As written, this setup creates neither the parent nor src/Lib/Lib.csproj, so the subsequent dotnet sln commands can't work. Create the solution and project, add the project to the parent, and then create the filter.

Starting with .NET 11, you can create a [solution filter](/visualstudio/msbuild/solution-filters) (*.slnf* file) with the `slnf` template:

```dotnetcli
dotnet new slnf --name MyApp.slnf

- **Files reviewed:** 5/5 changed files
- **Comments generated:** 4
- **Review effort level:** Lite
</details>