Command-line-api: Usage shows Project name instead of the tool name.

[srsaggam]

Example I have something as follows :
I have Bar.csproj as follows.

 <PackAsTool>true</PackAsTool>
 <ToolCommandName>foo</ToolCommandName>

The usage of the command is shown as follows when we type the command foo.

Usage:
  Bar [options] [command]

Options:
  --version    Display version information

I Was expecting :

Usage:
  foo [options] [command]

Options:
  --version    Display version information

Is this a bug or by design? If not please advise on how to package. Thank you.

[srsaggam]

FYI, @CESARDELATORRE @vinodshanbhag @rjoshi @justinormont

[srsaggam]

@jonsequitur

[jonsequitur]

@wli3 Any ideas on this one?

[wli3]

I don't think there is an easy way. What in "ToolCommandName" will not pass to compiler at all. It will end up in a xml file tool package and during "dotnet tool install" CLI will read that xml and create the shim according to it.

We need to check and see if there is a field in reflection can somehow get the original shim(apphost/muxer)'s path.

[zivkan]

The author of the tool could put <AssemblyName>$(ToolCommandName)</AssemblyName> in their csproj. Would it be worthwhile asking the SDK team to make this default when PackAsTool is true?

[wli3]

automatic setting AssemblyName is a bit too much. People will be surprised by this behavior. And I also think it should be able to fixed in system.commandline layer. Instead of using assembly name, find someway to get the apphost name.

[jonsequitur]

The current workaround for this is to set RootCommand.Name to the desired name.

[belgaard]

Maybe you should have a peek at a competitor who seems to not have the problem https://natemcmaster.github.io/CommandLineUtils/?

I'm not sure how it's done, but according to the blogs which describes its usage, it simply works https://moscardino.net/2019/12/making-a-cli-with-net-core/

[jonsequitur]

It looks like CommandLineUtils requires a similar workaround, which is to reiterate the tool name in the C# code. From the sample (comment mine):

namespace SampleCLI
{
    [Command(Name = "sample-cli",                       // <-- At runtime, the tool name comes from this, not from build metadata
            FullName = "Sample CLI",
            Description = "A sample CLI tool.")]
    [VersionOptionFromMember(MemberName = "GetVersion")]
    [HelpOption]
    public class MainCommand

[belgaard]

It looks like CommandLineUtils requires a similar workaround, which is to reiterate the tool name in the C# code. From the sample (comment mine):

namespace SampleCLI
{
    [Command(Name = "sample-cli",                       // <-- At runtime, the tool name comes from this, not from build metadata
            FullName = "Sample CLI",
            Description = "A sample CLI tool.")]
    [VersionOptionFromMember(MemberName = "GetVersion")]
    [HelpOption]
    public class MainCommand

OK, that's fair enough. In fact, I am quite happy with your workaround as it is.

[twsouthwick]

How about defaulting to the current process name? That way it will be whatever was invoked. I got it working by the following:

using (var current = System.Diagnostics.Process.GetCurrentProcess())
{
    root.Name = current.ProcessName;
}

I've tested this on Windows, but not linux yet.