[Breaking change]: --interactive option for dotnet CLI can now default to true in user-centric scenarios #45548
Description
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
- Binary incompatible: Existing binaries might encounter a breaking change in behavior, such as failure to load or execute, and if so, require recompilation.
- Source incompatible: When recompiled using the new SDK or component or to target the new runtime, existing source code might require source changes to compile successfully.
- Behavioral change: Existing binaries might behave differently at run time.
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