Tool name is `dotnet-fsharplint` while documentation states `fsharplint`

[xperiandri]

The project definition has <AssemblyName>dotnet-fsharplint</AssemblyName>, which means that the command is dotnet-fsharplint by default.
I think that we should use <ToolCommandName>fsharplint</ToolCommandName> (or set the assembly name) to align with the documentation.
I don't see any reason to prepend the command with dotnet-prefix.

@knocte @webwarrior-ws @Numpsy @Thorium do you have any thoughts?

[knocte]

I wish it was fsharplint too, without the dotnet- prefix. But I have the feeling that it is like that because of some issue with the nuget package that mapped to the fsharplint dotnet tool. And I was not a maintainer when this transition happened so I don't know the details. We could just try to recover it and see what issue we find.

[Numpsy]

It appears that there is already an 'FSharpLint' NuGet package that isn't the dotnet tool, so pushing out the tool with that package name might be a breaking change for anyone who still happens to be using the old version?

I have an idea that Fantomas had a similar situation in the past (the current 'fantomas' package is the dotnet tool, but it was originally the library and then things were renamed), so I think it can be done breaking changes aside

[baronfel]

👋 .NET SDK and .NET tools maintainer here.

The name of a binary impacts how the dotnet CLI can locate it, as does how the tool is installed.

Tool Name	Tool Install Type	User Invocation	Success?
dotnet-fsharplint	global	dotnet-fsharplint	✅
dotnet-fsharplint	global	dotnet fsharplint	✅
dotnet-fsharplint	global	fsharplint	❌
dotnet-fsharplint	local	dotnet-fsharplint	❌
dotnet-fsharplint	local	dotnet dotnet-fsharplint	✅
fsharplint	local	dotnet fsharplint	✅
fsharplint	global	dotnet-fsharplint	❌
fsharplint	global	dotnet fsharplint	❌

This is because the dotnet CLI itself has handling when users call dotnet <some unknown command> - if the CLI doesn't itself supply the command, it shells out to any program called dotnet-<some unknown command> that happens to be on the PATH.

It's a confusing situation overall. Starting in .NET 10 preview 6, we're hoping the new dnx feature will unify all of this. Folks should be able to just do dnx <tool package name> and local/global tools will be acquired and invoked automatically. Look for more news with the p6 release starting tomorrow.

[xperiandri]

@baronfel how does ToolCommandName project property affect this?

[baronfel]

ToolCommandName directly controls (and overwrites AssemblyName) the value of the first column of my table above. It's the name of any generated binaries that are generated for global tools, and it controls how the user invokes the local tool with dotnet <local tool name>.

It would have no impact on dnx, because dnx requires the tool package id, not the command name today. This is because multiple tool packages could have a duplicate command name.