|
2 | 2 |
|
3 | 3 | Here's a summary of what's new in the .NET SDK in this preview release: |
4 | 4 |
|
5 | | -- [Feature](#feature) |
| 5 | +- [.NET SDK in .NET 10 Preview 3 - Release Notes](#net-sdk-in-net-10-preview-3---release-notes) |
| 6 | + - [CLI](#cli) |
| 7 | + - [The `--interactive` option is now...interactive!](#the---interactive-option-is-nowinteractive) |
| 8 | + - [Native Shell Tab-Completion scripts](#native-shell-tab-completion-scripts) |
| 9 | + - [Containers](#containers) |
| 10 | + - [Console apps can natively create container images](#console-apps-can-natively-create-container-images) |
| 11 | + - [Explicitly control the image format of containers](#explicitly-control-the-image-format-of-containers) |
| 12 | + - [Testing](#testing) |
| 13 | + - [Support for Microsoft Testing Platform in `dotnet test`](#support-for-microsoft-testing-platform-in-dotnet-test) |
| 14 | + |
6 | 15 |
|
7 | 16 | .NET SDK updates in .NET 10: |
8 | 17 |
|
9 | | -- [What's new in .NET 10](https://learn.microsoft.com/dotnet/core/whats-new/dotnet-10/overview) documentation |
| 18 | +- [What's new in .NET 10](https://learn.microsoft.com/dotnet/core/whats-new/dotnet-10/overview#net-sdk) documentation |
| 19 | + |
| 20 | +## CLI |
| 21 | + |
| 22 | +### The `--interactive` option is now...interactive! |
| 23 | + |
| 24 | +The `--interactive` flag exists on many commands, where it is used to allow or disallow the command to change its behavior based on whether it is running in an interactive terminal or not. The primary use of this flag so far has been to enable commands that use NuGet to use NuGet's credential provider systems to dynamically retrieve credentials during the operation. Today, when using authenticated feeds, if the `--interactive` flag is not set, the command will fail with a message indicating that the command needs to be run with `--interactive` to succeed. This is not a great experience. |
| 25 | + |
| 26 | +Starting in .NET 10.0.100 preview 3, the `--interactive` flag will be enabled by default for all uses of the CLI that we think are interactive - specifically those where the command output hasn't been redirected, as well as those that are not running in an environment that we think is a CI/CD server. This is similar to how the capability detection for the MSBuild Terminal Logger output works, which we introduced in .NET 8. As a result, most uses of the CLI will not need to specify `--interactive` at all to have user-friendly behaviors. |
| 27 | + |
| 28 | +In the future, we will likely be keying more interactive behaviors, like prompting, progress bars, and more, off of this flag as well. This will allow us to make the CLI more user-friendly in interactive scenarios, while still allowing for non-interactive scenarios to work as expected. |
| 29 | + |
| 30 | +If a command should run without any interactive behaviors at all, you can still specify `--interactive false` to disable any interactivity. |
| 31 | + |
| 32 | +### Native Shell Tab-Completion scripts |
| 33 | + |
| 34 | +Today the `dotnet` CLI supports tab-completion for many shells, but actually configuring the shell to trigger the tab-completion is so difficult and un-advertised that most users don't know it exists. In .NET 10, we are introducing a new command, `dotnet completions generate [SHELL]`, which will generate tab-completion scripts for many common shells. In addition, for the most common shells the scripts we generate are _native_ to the shell, meaning that they will be able to use the shell's native tab-completion features. This means that you will get the same experience as if you had written the tab-completion script yourself, but without needing to know how to write it. These native scripts should be much faster than the dynamic completion mechanisms we have used in the past. |
| 35 | + |
| 36 | +In this release, we support the following shells: |
| 37 | + |
| 38 | +| Shell | Completion type | Additional features | |
| 39 | +| ---------- | --------------- | --------------------------------------------------------------- | |
| 40 | +| bash | hybrid | - | |
| 41 | +| fish | dynamic | - | |
| 42 | +| nushell | dynamic | - | |
| 43 | +| powershell | hybrid | Descriptions are available for commands, options, and arguments | |
| 44 | +| zsh | hybrid | Descriptions are available for commands, options, and arguments | |
| 45 | + |
| 46 | +In this chart, `dynamic` means that the script will call back to the `dotnet` CLI to get the list of commands, options, and arguments. This is the same mechanism we have used in the past. `hybrid` means that the script will use a combination of static and dynamic completion. For example, in `bash`, we will generate a static script for all of the commands and options, but we will still call back to the `dotnet` CLI to get completions for NuGet package names. This allows us to provide a much faster experience than we have in the past for common operations, while still allowing us to provide a full-featured experience. |
| 47 | + |
| 48 | +To use the new scripts, you will need to run the `dotnet completions generate [SHELL]` command. This will generate a script that you can source in your shell. For example, to generate a script for `pwsh`, you could add the following to your $PROFILE$: |
| 49 | + |
| 50 | +```powershell |
| 51 | +dotnet completions script pwsh | out-String | Invoke-Expression -ErrorAction SilentlyContinue |
| 52 | +``` |
| 53 | + |
| 54 | +This will generate a script that will be run every time you start a new PowerShell session. You can also run the command manually to generate the script and source it in your current session. Similar mechanisms can be used for the other supported shells! |
| 55 | + |
| 56 | +The overall completions-generation mechanisms are pluggable, so if you'd like to see new shells supported or enhancements made to your existing shell's scripts, raise an issue over at dotnet/sdk! |
| 57 | + |
| 58 | +## Containers |
| 59 | + |
| 60 | +### Console apps can natively create container images |
| 61 | + |
| 62 | +Console apps can now create container images via `dotnet publish /t:PublishContainer` without having to set the `<EnableSdkContainerSupport>` property to `true` in the project file. This brings them into line with the existing behavior for ASP.NET Core apps and Worker SDK apps, which have supported this for a while. If you need to disable this support for any reason, you can set the `<EnableSdkContainerSupport>` property to `false` in the project file. |
| 63 | + |
| 64 | +### Explicitly control the image format of containers |
| 65 | + |
| 66 | +The container images the .NET SDK produces today are either in a Docker-specific format or the more standardized OCI format. Which one our tooling uses is based on two things - if the container is a multi-architecture container, and the format of the base image being used. If the container is a multi-architecture container, we will always use the OCI format. Otherwise, for single-architecture containers, we will use the format of the base image. This means that any container generated using the Microsoft .NET base images will be in the Docker formats. Many users are moving to OCI images across their tooling, and so we have added a new property to the SDK, `<ContainerImageFormat>`, which allows you to explicitly set the format of the container image. This property can be set to `Docker` or `OCI`, and will override the default behavior. This property is only used when building a container image, and will not affect any other operations. |
| 67 | + |
| 68 | +## Testing |
| 69 | + |
| 70 | +### Support for Microsoft Testing Platform in `dotnet test` |
| 71 | + |
| 72 | +Starting with .NET 10 Preview 3, `dotnet test` now natively supports the [Microsoft.Testing.Platform](https://aka.ms/mtp-overview). You can enable this feature by adding the following configuration to your dotnet.config file (which itself is a [draft specification](https://github.com/dotnet/designs/pull/328) that we would love your feedback on): |
| 73 | + |
| 74 | + ```ini |
| 75 | + [dotnet.test:runner] |
| 76 | + name = "Microsoft.Testing.Platform" |
| 77 | + ``` |
10 | 78 |
|
11 | | -## Feature |
| 79 | +> [!NOTE] |
| 80 | +> The `[dotnet.test:runner]` part will change to `[dotnet.test.runner]` in Preview 4. |
12 | 81 |
|
13 | | -Something about the feature |
| 82 | +For more details, refer to [Testing with `dotnet test`](https://learn.microsoft.com/dotnet/core/testing/unit-testing-with-dotnet-test), which explains how Microsoft.Testing.Platform was integrated with `dotnet test` in .NET 9 and earlier versions, and the reasons behind the new `dotnet test` experience. |
0 commit comments