This article describes new features and enhancements in the .NET SDK for .NET 10. It has been updated for Preview 6.

.NET tools enhancements

Platform-specific .NET tools

.NET tools can now be published with support for multiple RuntimeIdentifiers (RIDs) in a single package. Tool authors can bundle binaries for all supported platforms, and the .NET CLI will select the correct one at install or run time. This makes cross-platform tool authoring and distribution much easier.

These enhanced tools support various packaging variations:

• Framework-dependent, platform-agnostic (classic mode, runs anywhere with .NET 10 installed)
• Framework-dependent, platform-specific (smaller, optimized for each platform)
• Self-contained, platform-specific (includes the runtime, no .NET installation required)
• Trimmed, platform-specific (smaller, trims unused code)
• AOT-compiled, platform-specific (maximum performance and smallest deployment)

These new tools work much like normal published applications, so any publishing options you can use with applications (for example, self-contained, trimmed, or AOT) can apply to tools as well.

One-shot tool execution

You can now use thedotnet tool exec command to execute a .NET tool without installing it globally or locally. This is especially valuable for CI/CD or ephemeral usage.

dotnet tool exec --source ./artifacts/package/ toolsay "Hello, World!"Tool package toolsay@1.0.0 will be downloaded from source <source>.Proceed? [y/n] (y): y  _   _          _   _                __        __                 _       _   _ | | | |   ___  | | | |   ___         \ \      / /   ___    _ __  | |   __| | | | | |_| |  / _ \ | | | |  / _ \         \ \ /\ / /   / _ \  | '__| | |  / _` | | | |  _  | |  __/ | | | | | (_) |  _      \ V  V /   | (_) | | |    | | | (_| | |_| |_| |_|  \___| |_| |_|  \___/  ( )      \_/\_/     \___/  |_|    |_|  \__,_| (_)                                |/

This downloads and runs the specified tool package in one command. By default, users are prompted to confirm the download if the tool doesn't already exist locally. The latest version of the chosen tool package is used unless an explicit version is specified (for example,toolsay@0.1.0).

One-shot tool execution works seamlessly with local tool manifests. If you run a tool from a location containing a.config/dotnet-tools.json nearby, the version of the tool in that configuration will be used instead of the latest version available.

The newdnx tool execution script

Thednx script provides a streamlined way to execute tools. It forwards all arguments to thedotnet CLI for processing, making tool usage as simple as possible:

dnx toolsay "Hello, World!"

The actual implementation of thednx command is in thedotnet CLI itself, allowing its behavior to evolve over time.

For more information about managing .NET tools, seeManage .NET tools.

CLI introspection with--cli-schema

A new--cli-schema option is available on all CLI commands. When used, it outputs a JSON representation of the CLI command tree for the invoked command or subcommand. This is useful for tool authors, shell integration, and advanced scripting.

dotnet clean --cli-schema

The output provides a structured, machine-readable description of the command's arguments, options, and subcommands:

{  "name": "clean",  "version": "10.0.100-dev",  "description": ".NET Clean Command",  "arguments": {    "PROJECT | SOLUTION": {      "description": "The project or solution file to operate on. If a file is not specified, the command will search the current directory for one.",      "arity": { "minimum": 0, "maximum": null }    }  },  "options": {    "--artifacts-path": {      "description": "The artifacts path. All output from the project, including build, publish, and pack output, will go in subfolders under the specified path.",      "helpName": "ARTIFACTS_DIR"    }  },  "subcommands": {}}

File-based apps enhancements

.NET 10 brings significant updates to the file-based apps experience, including publish support and native AOT capabilities. For an introduction to file-based programs, seeFile based programs andBuilding and running C# programs.

Enhanced file-based apps with publish support and native AOT

File-based apps now support being published to native executables via thedotnet publish app.cs command, making it easier to create simple apps that you can redistribute as native executables. All file-based apps now target native AOT by default. If you need to use packages or features that are incompatible with native AOT, you can disable this using the#:property PublishAot=false directive in your .cs file.

File-based apps also include enhanced features:

• Project referencing: Support for referencing projects via the#:project directive.
• Runtime path access: App file and directory paths are available at runtime viaSystem.AppContext.GetData.
• Enhanced shebang support: Direct shell execution with improved shebang handling, including support for extensionless files.

Project referencing example

#:project ../ClassLib/ClassLib.csprojvar greeter = new ClassLib.Greeter();var greeting = greeter.Greet(args.Length > 0 ? args[0] : "World");Console.WriteLine(greeting);

Enhanced shebang support example

You can now create executable C# files that run directly from the shell:

#!/usr/bin/env dotnetConsole.WriteLine("Hello shebang!");

For extensionless files:

# 1. Create a single-file C# app with a shebangcat << 'EOF' > hello.cs#!/usr/bin/env dotnetConsole.WriteLine("Hello!");EOF# 2. Copy it (extensionless) into ~/utils/hello (~/utils is on my PATH)mkdir -p ~/utilscp hello.cs ~/utils/hello# 3. Mark it executablechmod +x ~/utils/hello# 4. Run it directly from anywherecd ~hello

These enhancements make file-based apps more powerful while maintaining their simplicity for quick scripting and prototyping scenarios.

For more information about native AOT, see.NET native AOT.

Pruning of framework-provided package references

Starting in .NET 10, theNuGet Audit feature can nowprune framework-provided package references that aren't used by the project. This feature is enabled by default for allnet target frameworks (for example,net8.0 andnet10.0) and .NET Standard 2.0 and greater target frameworks. This change helps reduce the number of packages that are restored and analyzed during the build process, which can lead to faster build times and reduced disk space usage. It also can lead to a reduction in false positives from NuGet Audit and other dependency-scanning mechanisms.

When this feature is enabled, you might see a reduction in the contents of your applications' generated.deps.json files. Any package references supplied by the .NET runtime are automatically removed from the generated dependency file.

While this feature is enabled by default for the listed TFMs, you can disable it by setting theRestoreEnablePackagePruning property tofalse in your project file orDirectory.Build.props file.

More consistent command order

Starting in .NET 10, thedotnet CLI tool includes new aliases for common commands to make them easier to remember and type. The new commands are shown in the following table.

The new noun-first forms align with general CLI standards, making thedotnet CLI more consistent with other tools. While the verb-first forms continue to work, it's better to use the noun-first forms for improved readability and consistency in scripts and documentation.

CLI commands default to interactive mode in interactive terminals

The--interactive flag is now enabled by default for CLI commands in interactive terminals. This change allows commands to dynamically retrieve credentials or perform other interactive behaviors without requiring the flag to be explicitly set. For noninteractive scenarios, you can disable interactivity by specifying--interactive false.

Native shell tab-completion scripts

Thedotnet CLI now supports generating native tab-completion scripts for popular shells using thedotnet completions generate [SHELL] command. Supported shells includebash,fish,nushell,powershell, andzsh. These scripts improve usability by providing faster and more integrated tab-completion features. For example, in PowerShell, you can enable completions by adding the following to your$PROFILE:

dotnet completions script pwsh | out-String | Invoke-Expression -ErrorAction SilentlyContinue

Console apps can natively create container images

Console apps can now create container images viadotnet publish /t:PublishContainer without requiring the<EnableSdkContainerSupport> property in the project file. This aligns console apps with the behavior of ASP.NET Core and Worker SDK apps.

Explicitly control the image format of containers

A new<ContainerImageFormat> property allows you to explicitly set the format of container images to eitherDocker orOCI. This property overrides the default behavior, which depends on the base image format and whether the container is multi-architecture.

Support for Microsoft Testing Platform indotnet test

Starting in .NET 10,dotnet test natively supportsMicrosoft.Testing.Platform. To enable this feature, add the following configuration to yourdotnet.config file:

[dotnet.test.runner]name = "Microsoft.Testing.Platform"

For more details, seeTesting withdotnet test.