dotnet commands should not output usage information on all errors

[zivkan]

NuGet Product(s) Affected

dotnet.exe

Current Behavior

> dotnet nuget remove source ashjdfsbf
error: Unable to find any package source(s) matching name: ashjdfsbf.


Usage: dotnet nuget remove source [arguments] [options]

Arguments:
  name  Name of the source.

Options:
  --configfile  The NuGet configuration file. If specified, only the settings from this file will be used. If not specified, the hierarchy of configuration files from the current directory will be used. For more information, see https://docs.microsoft.com/nuget/consume-packages/configuring-nuget-behavior.
  -h|--help     Show help information

However, a scenario that is more likely to confuse customers is:

> dotnet add package snjfbdujfbdf
  Determining projects to restore...
  Writing C:\Users\zivkan\AppData\Local\Temp\tmp255fey.tmp
info : X.509 certificate chain validation will use the default trust store selected by .NET for code signing.
info : X.509 certificate chain validation will use the default trust store selected by .NET for timestamping.
info : Adding PackageReference for package 'snjfbdujfbdf' into project 'D:\src\test\wtf\wtf.csproj'.
info :   GET https://api.nuget.org/v3/registration5-gz-semver2/snjfbdujfbdf/index.json
info :   NotFound https://api.nuget.org/v3/registration5-gz-semver2/snjfbdujfbdf/index.json 238ms
info :   GET https://api.nuget.org/v3/registration5-gz-semver2/snjfbdujfbdf/index.json
info :   NotFound https://api.nuget.org/v3/registration5-gz-semver2/snjfbdujfbdf/index.json 162ms
error: There are no versions available for the package 'snjfbdujfbdf'.


Usage: NuGet.CommandLine.XPlat.dll package add [options]

Options:
  -h|--help               Show help information
  --force-english-output  Forces the application to run using an invariant, English-based culture.
  --package               Id of the package to be added.
  --version               Version of the package to be added.
  -d|--dg-file            Path to the dependency graph file to be used to restore preview and compatibility check.
  -p|--project            Path to the project file.
  -f|--framework          Frameworks for which the package reference should be added.
  -n|--no-restore         Do not perform restore preview and compatibility check. The added package reference will be unconditional.
  -s|--source             Specifies NuGet package sources to use during the restore.
  --package-directory     Directory to restore packages in.
  --interactive           Allow the command to block and require manual action for operations like authentication.
  --prerelease            Allows prerelease packages to be installed.

Desired Behavior

Only show usage/help information when command line parsing fails, not on all failures.

For example, run dotnet add package Some.Package.That.Does.Not.Exist. If done in a directory that does not contain any *.*proj file it outputs:

Could not find any project in `D:\src\test\`.

That's it, no usage information. Whereas, if I add --arg-that-does-not-exist, then I get an error message saying the argument is not recognised, followed by the usage/help information.

This is a pattern that most CLI apps use.

Additional Context

I believe that customers are getting confused by the extra verbosity in the error message, especially in the dotnet add package scenario where neither the first line nor the last line of the message output to customers is an error message. We have gotten github issues and VS feedback where the error message states what the problem is, but customers don't seem to notice and report the issue to us rather than fixing the issue themselves.

[nkolev92]

Is this a regression?

[zivkan]

I don't think so, but I'm not 100% sure.