Description
Starting in .NET 10.0.100 preview 3, the --interactive CLI flag will now default to true in scenarios where a user is directly invoking CLI commands. This is part of a series of changes that should make authentication to NuGet feeds more seamless, as well as enabling future CLI UX features that depend on interactivity.
Version
.NET 10 Preview 3
Previous behavior
The --interactive flag would always default to false unless explicitly specified by a user.
New behavior
The --interactive flag will default to true if the execution environment is not a CI/CD system (as detected via certain environment variables commonly used for signalling this) or if the process output stream has been redirected. Put simply, if a user typed dotnet <blah> that would be an interactive session, but if a CI/CD script ran dotnet <blah> that would not be an interactive session.
Type of breaking change
Reason for change
The overall justification is captured in dotnet/sdk#46421.
Broadly, we're doing this to
a) have a unified signal for CLI developers to use to light up interactivity features in the future, and
b) have better defaults for NuGet authentication, reducing a very commonly expressed user pain point
The implementation was done in dotnet/sdk#47226.
Recommended action
There should be no action required for most users. If you need to explicitly disable interactivity, passing --interactive false will disable the feature.
Feature area
SDK
Affected APIs
No response
Associated WorkItem - 417522
Description
Starting in .NET 10.0.100 preview 3, the
--interactiveCLI flag will now default totruein scenarios where a user is directly invoking CLI commands. This is part of a series of changes that should make authentication to NuGet feeds more seamless, as well as enabling future CLI UX features that depend on interactivity.Version
.NET 10 Preview 3
Previous behavior
The
--interactiveflag would always default tofalseunless explicitly specified by a user.New behavior
The
--interactiveflag will default to true if the execution environment is not a CI/CD system (as detected via certain environment variables commonly used for signalling this) or if the process output stream has been redirected. Put simply, if a user typeddotnet <blah>that would be an interactive session, but if a CI/CD script randotnet <blah>that would not be an interactive session.Type of breaking change
Reason for change
The overall justification is captured in dotnet/sdk#46421.
Broadly, we're doing this to
a) have a unified signal for CLI developers to use to light up interactivity features in the future, and
b) have better defaults for NuGet authentication, reducing a very commonly expressed user pain point
The implementation was done in dotnet/sdk#47226.
Recommended action
There should be no action required for most users. If you need to explicitly disable interactivity, passing
--interactive falsewill disable the feature.Feature area
SDK
Affected APIs
No response
Associated WorkItem - 417522