Consider a different name for Dragonfruit

[jonsequitur]

No description provided.

[adamskt]

How about: ArgumentAppModel for DragonFruit and AttributeAppModel for Starfruit?

[tmds]

Suggestion: The DragonFruit Main is now named Main, it could be named CliMain and the DragonFruit package can have the same name (CliMain).
Perhaps this also solves an ambiguity issue where both the DragonFruit Main and the entrypoint Main take a string[] argument or no arguments.

[jonsequitur]

If there's no user-defined strongly-typed Main, then a user-defined Main(string[]) does work.

If the user defines both kinds of Main methods, there'll be a compiler error, which I think is the right behavior. CliMain seems like more of a new concept than the alternate Main. That said, we haven't come up with a convention for subcommands with DragonFruit, but a few ideas have involved method naming, e.g. aligning method names with command names.

Along those lines, the entry point for foo.exe might reasonably be something like:

public static async Task<int> Foo(int something, bool somethingElse)
{
}

[tmds]

If there's no user-defined strongly-typed Main, then a user-defined Main(string[]) does work. If the user defines both kinds of Main methods, there'll be a compiler error, which I think is the right behavior.

The cases I'm thinking about:

• the application doesn't accept any options, in that case the strongly-typed Main has a signature: Main()
• the application accepts an option of type string[], in that case the strongly-typed Main has a signature: Main(string[] args)

In these two cases, the strongly-typed Main has the signature of a valid entry-point Main.
The user can work around it by adding an additional argument (e.g. IConsole).

[iCodeSometime]

In addition, choosing an alternate name for the main method of a DragonFruit app (like CliMain) would prevent ambiguous reference problems with other auto-generated main methods, e.g. if the CLI app is actually sometimes a WPF app.