dotnet CLI: "dotnet help new" does not work

[ajpinedam]

Describe the bug

dotnet help new following the documentation and how similar commands behave should open the new command documentation website. Instead, this is different from the current behavior on 9.0.100. Executing that command returns the help command information.

Tested this on Windows, macOS, and Linux (Mint).

Below is a sample running on macOS:

dotnet_help_new.mov

To Reproduce

Exceptions (if any)

Further technical details

• Include the output of dotnet --info

dotnet --info

➜  ~ dotnet --info
.NET SDK:
 Version:           9.0.100
 Commit:            59db016f11
 Workload version:  9.0.100-manifests.c6f19616
 MSBuild version:   17.12.7+5b8665660

Runtime Environment:
 OS Name:     Mac OS X
 OS Version:  14.6
 OS Platform: Darwin
 RID:         osx-x64
 Base Path:   /usr/local/share/dotnet/sdk/9.0.100/

.NET workloads installed:
 [wasm-tools]
   Installation Source: SDK 9.0.100
   Manifest Version:    9.0.0/9.0.100
   Manifest Path:       /usr/local/share/dotnet/sdk-manifests/9.0.100/microsoft.net.workload.mono.toolchain.current/9.0.0/WorkloadManifest.json
   Install Type:        FileBased

 [macos]
   Installation Source: SDK 9.0.100
   Manifest Version:    15.0.9617/9.0.100
   Manifest Path:       /usr/local/share/dotnet/sdk-manifests/9.0.100/microsoft.net.sdk.macos/15.0.9617/WorkloadManifest.json
   Install Type:        FileBased

 [ios]
   Installation Source: SDK 9.0.100
   Manifest Version:    18.0.9617/9.0.100
   Manifest Path:       /usr/local/share/dotnet/sdk-manifests/9.0.100/microsoft.net.sdk.ios/18.0.9617/WorkloadManifest.json
   Install Type:        FileBased

 [maccatalyst]
   Installation Source: SDK 9.0.100
   Manifest Version:    18.0.9617/9.0.100
   Manifest Path:       /usr/local/share/dotnet/sdk-manifests/9.0.100/microsoft.net.sdk.maccatalyst/18.0.9617/WorkloadManifest.json
   Install Type:        FileBased

 [maui]
   Installation Source: SDK 9.0.100
   Manifest Version:    9.0.0/9.0.100
   Manifest Path:       /usr/local/share/dotnet/sdk-manifests/9.0.100/microsoft.net.sdk.maui/9.0.0/WorkloadManifest.json
   Install Type:        FileBased

 [android]
   Installation Source: SDK 9.0.100
   Manifest Version:    35.0.7/9.0.100
   Manifest Path:       /usr/local/share/dotnet/sdk-manifests/9.0.100/microsoft.net.sdk.android/35.0.7/WorkloadManifest.json
   Install Type:        FileBased

Configured to use loose manifests when installing new manifests.

Host:
  Version:      9.0.0
  Architecture: x64
  Commit:       9d5a6a9aa4

.NET SDKs installed:
  6.0.425 [/usr/local/share/dotnet/sdk]
  7.0.317 [/usr/local/share/dotnet/sdk]
  8.0.401 [/usr/local/share/dotnet/sdk]
  8.0.404 [/usr/local/share/dotnet/sdk]
  9.0.100 [/usr/local/share/dotnet/sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 6.0.33 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 7.0.20 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 8.0.8 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 8.0.11 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 9.0.0 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 6.0.33 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 7.0.20 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 8.0.8 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 8.0.11 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 9.0.0 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]

Other architectures found:
  None

Environment variables:
  Not set

global.json file:
  Not found

Learn more:
  https://aka.ms/dotnet/info

Download .NET:
  https://aka.ms/dotnet/download

• The IDE (VS / VS Code/ VS4Mac) you're running on, and its version

[ajpinedam]

For whoever is triaging this issue, I would like to try it and find a fix for it.

[Forgind]

Some commands seem to act this way, and others don't. dotnet new seems like a reasonable one to do what you expect. (Its spew seems to be because it's throwing an error currently.)

I'll mark it for team triage. If we get consensus, I can assign it to you, and we'd welcome a PR for it 🙂

[baronfel]

What's happening here is that the NewCommand isn't an DocumentedCommand and so we just write the usage of the dotnet CLI itself. This is maybe not the best experience. We should do the following:

• NewCommand can't be a DocumentedCommand due to multiple inheritance so we'd need another marker interface to signal a docs url, and then incorporate that into TryGetDocsLink
• If TryGetDocsLink fails but the command is a known command (it parses successfully) we should just write the Help output for that command. For example dotnet help new should be the same as dotnet new --help if no url is available.
• Only show the usage we do today if the command given to dotnet help is completely unknown.

[ajpinedam]

@baronfel Thanks for the details.

I understand that the option of adding an interface that both DocumentedComand and NewCommand implement, something like ICommandDocument and then checking on the TryGetDocsLink method for that interface should give us what we need.

I can put a draft PR to keep the discussion there.