Getting started

Install the library to your console app project with NuGet.

In your project directory, via dotnet cli:

or in Visual Studio Package Manager Console:

Prerequisites

• .NET 8.0 and later project or .NET Standard 2.0 and later project.
  Note that .NET Framework 4.7.2+ or .NET Core 2.0 to NET 7.0 projects can reference our netstandard2.0 target (automatic in nuget).
  If your target framework is below net5.0, you also need <LangVersion>9.0</LangVersion> tag (minimum) in your .csproj file.
• Visual Studio 2022 v17.3+ or .NET SDK 6.0.407+ (when building via dotnet cli).
  Our incremental source generator requires performance features added first in these versions.
• Usually a console app project but you can also use a class library project which will be consumed later.

Usage

DotMake.CommandLine offers 2 models: class-based model and delegate-based model. Delegate-based model is useful for simple apps, for more complex apps, you should use the class-based model because you can have sub-commands and command inheritance.

Class-based model

Create a CLI App with DotMake.Commandline in seconds!

In Program.cs, add this simple code:

And that's it! You now have a fully working command-line app. You just specify the name of your class which represents your root command to Cli.Run<> method and everything is wired.

args is the string array typically passed to a program. This is usually the special variable args available in Program.cs (new style with top-level statements) or the string array passed to the program's Main method (old style). We also have method signatures which does not require args, for example you can also call Cli.Run<RootCliCommand>() and in that case args will be retrieved automatically from the current process via Cli.GetArgs().

If you want to go async, just use this:

To handle exceptions, you just use a try-catch block:

System.CommandLine, by default overtakes your exceptions that are thrown in command handlers (even if you don't set an exception handler explicitly) but DotMake.CommandLine, by default allows the exceptions to pass through. However if you wish, you can easily use the default exception handler by passing a CliSettings instance like below. Default exception handler prints the exception in red color to console:

If you need to simply parse the command-line arguments without invocation, use this:

If you need to examine the parse result, such as errors:

Summary

• Mark the class with CliCommand attribute to make it a CLI command (see CliCommandAttribute docs for more info).

• Mark a property with CliOption attribute to make it a CLI option (see CliOptionAttribute docs for more info).

• Mark a property with CliArgument attribute to make it a CLI argument (see CliArgumentAttribute docs for more info).

• Add a method with name Run or RunAsync to make it the handler for the CLI command. The method can have one of the following signatures:

  • void Run()
  • int Run()
  • async Task RunAsync()
  • async Task<int> RunAsync()

  Optionally the method signature can have a CliContext parameter in case you need to access it:

  • Run(CliContext context)
  • RunAsync(CliContext context)

  We also provide interfaces ICliRun, ICliRunWithReturn, ICliRunWithContext, ICliRunWithContextAndReturn and async versions ICliRunAsync, ICliRunAsyncWithReturn, ICliRunAsyncWithContext, ICliRunAsyncWithContextAndReturn that you can inherit in your command class. Normally you don't need an interface for a handler method as the source generator can detect it automatically, but the interfaces can be used to prevent your IDE complain about unused method in class.

  The signatures which return int value, sets the ExitCode of the app. If no handler method is provided, then by default it will show help for the command. This can be also controlled manually by extension method ShowHelp in CliContext. Other extension methods IsEmptyCommand, ShowValues and ShowHierarchy are also useful.

• Call Cli.Run<> orCli.RunAsync<> method with your class name to run your CLI app (see Cli docs for more info).

• For best practice, create a subfolder named Commands in your project and put your command classes there so that they are easy to locate and maintain in the future.

Delegate-based model

Create a CLI App with DotMake.Commandline in seconds!

In Program.cs, add this simple code:

And that's it! You now have a fully working command-line app.

Summary

• Pass a delegate (a parenthesized lambda expression or a method reference) which has parameters that represent your options and arguments, to Cli.Run.
• A parameter is by default considered as a CLI option but you can;
  • Mark a parameter with CliArgument attribute to make it a CLI argument and specify settings (see CliArgumentAttribute docs for more info).
  • Mark a parameter with CliOption attribute to specify CLI option settings (see CliOptionAttribute docs for more info).
  • Mark the delegate itself with CliCommand attribute to specify CLI command settings (see CliCommandAttribute docs for more info).
  • Note that for being able to mark a parameter with an attribute in an anonymous lambda function, if your target framework is below net6.0, you also need <LangVersion>10.0</LangVersion> tag (minimum) in your .csproj file.
• Set a default value for a parameter if you want it to be optional (not required to be specified on the command-line).
• Your delegate can be async.
• Your delegate can have a return type void or int and if it's async Task or Task<int>.

Trim self-contained deployment

Use this command in your project folder, e.g. for win-x64 platform:

If you have multiple TargetFrameworks in the project use this:

The output will be generated in bin\Release\net8.0\win-x64\publish folder. You will get a trimmed and single executable file which does not require .NET runtime (e.g. a 12MB exe file). More details on trimming.

Native AOT deployment

Use this command in your project folder, e.g. for win-x64 platform:

If you have multiple TargetFrameworks in the project use this:

The output will be generated in bin\Release\net8.0\win-x64\publish folder. You will get a native and single executable file for the platform, which runs blazingly fast (e.g. a 4MB exe file).

Note that for AOT, you need to make sure to install the "Desktop development with C++" workload from Visual Studio 2022 installer. Without it you may see errors like error Platform linker not found. Installer may take a while, for example it may seem stuck at Microsoft.VisualCpp.Redist14 but wait a few minutes and it will complete. More details on AOT compilation.

Help output

When you run the app via

• TestApp.exe -? in project output path (e.g. in TestApp\bin\Debug\net8.0)
• or dotnet run -- -? in project directory (e.g. in TestApp) (note the double hyphen/dash which allows dotnet run to pass arguments to our actual application)

You see this usage help:

Note the header:

• First line comes from AssemblyProductAttribute or AssemblyName (<Product> tag in your .csproj file).
  Version comes from AssemblyInformationalVersionAttribute or AssemblyFileVersionAttribute or AssemblyVersionAttribute (<InformationalVersion> or <FileVersion > or <Version> tag in your .csproj file).
• Second line comes from AssemblyCopyrightAttribute (<Copyright> tag in your .csproj file).
• Third line comes from AssemblyDescriptionAttribute (<Description> tag in your .csproj file) for root commands or from [CliCommand].Description property for subcommands.

Note, how command/directive/option/argument names, descriptions and default values are automatically populated.

By default, command/option/argument names are generated as follows;

• First the following suffixes are stripped out from class and property names:

  • For commands: "RootCliCommand", "RootCommand", "SubCliCommand", "SubCommand", "CliCommand", "Command", "Cli"
  • For directives: "Directive" or above command suffixes followed by "Directive", e.g. "CommandDirective"
  • For options: "Option" or above command suffixes followed by "Option", e.g. "CommandOption"
  • For arguments: "Argument" or above command suffixes followed by "Argument", e.g. "CommandArgument"

• Then the names are converted to kebab-case.
  (e.g. Info -> info,ServerPort -> server-port, Option1 -> option-1)
  This can be changed by setting [CliCommand].NameCasingConvention property to one of the following values:

  • CliNameCasingConvention.None
  • CliNameCasingConvention.LowerCase
  • CliNameCasingConvention.UpperCase
  • CliNameCasingConvention.TitleCase
  • CliNameCasingConvention.PascalCase
  • CliNameCasingConvention.CamelCase
  • CliNameCasingConvention.KebabCase
  • CliNameCasingConvention.SnakeCase

  For options, double hyphen/dash prefix is added to the name.
  (e.g. Info -> --info,ServerPort -> --server-port, Option1 -> --option-1)
  This can be changed by setting [CliCommand].NamePrefixConvention property (default: DoubleHyphen) to one of the following values:

  • CliNamePrefixConvention.None
  • CliNamePrefixConvention.SingleHyphen
  • CliNamePrefixConvention.DoubleHyphen
  • CliNamePrefixConvention.ForwardSlash

  When you set a specific name via [CliXXX].Name property, that will be used instead of a auto-generated name.
  For options, if you don't specify a prefix, it will be prefixed automatically according to [CliCommand].NamePrefixConvention
  (e.g. --option, -option or /option) unless it's set to CliNamePrefixConvention.None.

  Auto-generated names can be disabled for all or specific CLI symbol types via [CliCommand].NameAutoGenerate.

• For commands and options, a short form alias is automatically added. First letters of every word in the name will be used to create short form to reduce conflicts. These first letters are converted according to [CliCommand].NameCasingConvention property.
  (e.g. Info -> i,ServerPort -> sp, Option1 -> o1)

  For options, single hyphen/dash prefix is added to the short form.
  (e.g. Info -> -i,ServerPort -> -sp, Option1 -> -o1)
  This can be changed via [CliCommand].ShortFormPrefixConvention property (default: SingleHyphen).

  When you set a specific alias via [CliXXX].Alias property, that will be used instead of a auto-generated short form alias.
  For options, if you don't specify a prefix, it will be prefixed automatically according to [CliCommand].ShortFormPrefixConvention
  (e.g. -o or --o or /o) unless it's set to CliNamePrefixConvention.None.

  Auto-generated short form aliases can be disabled for all or specific CLI symbol types via [CliCommand].ShortFormAutoGenerate.

For example, change the name casing and prefix convention:

When you run the app via TestApp.exe -? or dotnet run -- -?, you see this usage help:

Note how even the default options version and help use the new prefix convention ForwardSlash. By the way, as help is a special option, which allows user to discover your app, we still add short form aliases with other prefix to prevent confusion.

Themes

Cli app theme can be changed via setting CliSettings.Theme property to predefined themes Red, DarkRed, Green, DarkGreen, Blue, DarkBlue or a custom CliTheme. These color and formatting option are mainly used by the help output.

Note that NO_COLOR is supported, i.e. if NO_COLOR environment variable is set, the colors will be disabled.

Localization

Localizing commands, options and arguments is supported. You can specify a nameof operator expression with a resource property (generated by resx) in the attribute's argument (for string types only) and the source generator will smartly use the resource property accessor as the value of the argument so that it can localize at runtime. If the property in the nameof operator expression does not point to a resource property, then the name of that property will be used as usual. The reason we use nameof operator is that attributes in .NET only accept compile-time constants and you get CS0182 error if not, so specifying resource property directly is not possible as it's not a compile-time constant but it's a static property access.

Triggering help

If a command represents a group and not an action, you may want to show help. If Run or RunAsync method is missing in a command class, then by default it will show help. You can also manually trigger help in Run or RunAsync method of a command class via calling CliContext.ShowHelp. For testing a command, these methods are also useful:

• CliContext.IsEmptyCommand gets value indicating whether current command is specified without any arguments or options. Note that arguments and options should be optional, if they are required (no default values), then handler will not run and missing error message will be shown.
• CliContext.ShowValues shows parsed values for current command and its arguments and options.
• CliContext.ShowHierarchy shows hierarchy for all commands, it will start from the root command and show a tree.

See below example; root command does not have a handler method so it will always show help and sub-command will show help if command is specified without any arguments or option, and it will show (dump) values if not:

Commands

A command in command-line input is a token that specifies an action or defines a group of related actions. For example:

• In dotnet run, run is a command that specifies an action.
• In dotnet tool install, install is a command that specifies an action, and tool is a command that specifies a group of related commands. There are other tool-related commands, such as tool uninstall, tool list, and tool update.

Root commands

The root command is the one that specifies the name of the app's executable. For example, the dotnet command specifies the dotnet.exe executable.

Subcommands

Most command-line apps support subcommands, also known as verbs. For example, the dotnet command has a run subcommand that you invoke by entering dotnet run.

Subcommands can have their own subcommands. In dotnet tool install, install is a subcommand of tool.

Command Hierarchy

Defining sub-commands in DotMake.Commandline is very easy. We simply use nested classes to create a hierarchy. Just make sure you apply CliCommand attribute to the nested classes as well:

Another way to create hierarchy between commands, especially if you want to use standalone classes,
is to

• Use Children property of CliCommand attribute to specify array of typeof child classes:

• Use Parent property of CliCommand attribute to specify typeof parent class:

The class that CliCommand attribute is applied to,

• will be a root command if the class is not a nested class and other's Children property and self's Parent property is not set.
• will be a sub command if the class is a nested class or other's Children property or self's Parent property is set.

You can create a complex hierarchy like this by mixing nested classes and external classes:

Parent property can even refer to a nested class in another class, Children property can not because having a nested parent is higher priority. A nested child can use Children property to refer non-nested classes though.

Accessing parent commands

Sub-commands can get a reference to the parent command by adding a property of the parent command type.
Alternatively ParseResult.Bind<TDefinition> method can be called to manually get reference to a parent command.
Note that binding will be done only once per definition class, so calling this method consecutively for the same definition class will return the cached result.

Command Inheritance

When you have repeating/common options and arguments for your commands, you can define them once in a base class and then share them by inheriting that base class in other command classes. Interfaces are also supported !

The property attribute and the property initializer from the most derived class in the hierarchy will be used (they will override the base ones). The command handler (Run or RunAsync) will be also inherited. So in the above example, InheritanceCliCommand inherits options Username, Password from a base class and option Department from an interface. Note that the property initializer for Department is in the derived class, so that default value will be used.

The properties for CliCommand attribute (see CliCommandAttribute docs for more info):

• Name
• Description
• Alias
• Aliases
• Hidden
• Parent
• TreatUnmatchedTokensAsErrors
• NameAutoGenerate (inherited by subcommands, used for child commands, directives, options and arguments)
• NameCasingConvention (inherited by subcommands, used for child commands, directives, options and arguments)
• NamePrefixConvention (inherited by subcommands, used for child options)
• ShortFormAutoGenerate (inherited by subcommands, used for child commands and options)
• ShortFormPrefixConvention (inherited by subcommands, used for child options)

Options

An option is a named parameter that can be passed to a command. POSIX CLIs typically prefix the option name with two hyphens (--). The following example shows two options:

As this example illustrates, the value of the option may be explicit (quiet for --verbosity) or implicit (nothing follows --global). Options that have no value specified are typically Boolean parameters that default to true if the option is specified on the command line.

For some Windows command-line apps, you identify an option by using a leading slash (/) with the option name. For example:

Both POSIX and Windows prefix conventions are supported (e.g. --option, -o, -option or /option).

It's allowed to use a space, =, or : as the delimiter between an option name and its argument. For example, the following commands are equivalent:

A POSIX convention lets you omit the delimiter when you are specifying a single-character option alias. For example, the following commands are equivalent:

Bundling of single-character options are supported, also known as stacking. Bundled options are single-character option aliases specified together after a single hyphen prefix. For example if you have options "-a", "-b" and "-c", you can bundle them like "-abc". Only the last option can specify an argument. Note that if you have an explicit option named "-abc" then it will win over bundled options.

The properties for CliOption attribute (see CliOptionAttribute docs for more info):

• Name
• Description
• Alias
• Aliases
• HelpName
• Hidden
• Required
• Recursive
• Arity
• AllowedValues
• AllowMultipleArgumentsPerToken
• ValidationRules
• ValidationPattern
• ValidationMessage

Arguments

An argument is a value passed to an option or a command. The following examples show an argument for the verbosity option and an argument for the build command.

Arguments can have default values that apply if no argument is explicitly provided. For example, many options are implicitly Boolean parameters with a default of true when the option name is in the command line. The following command-line examples are equivalent:

Some options have required arguments. For example in the .NET CLI, --output requires a folder name argument. If the argument is not provided, the command fails.

Arguments can have expected types, and System.CommandLine displays an error message if an argument can't be parsed into the expected type. For example, the following command errors because "silent" isn't one of the valid values for --verbosity:

The properties for CliArgument attribute (see CliArgumentAttribute docs for more info):

• Name
• Description
• HelpName
• Hidden
• Required
• Arity
• AllowedValues
• ValidationRules
• ValidationPattern
• ValidationMessage

Model binding

When the command handler is run, the properties for CLI options and arguments will be already populated and bound from values passed in the command-line. If no matching value is passed, the property will have its default value if it has one or an error will be displayed if it's a required option/argument and it was not specified on the command-line.

An option/argument will be considered required when

• There is no property initializer and the property type is a reference type (e.g. public string Arg { get; set; }). string is a reference type which has a null as the default value but bool and enum are value types which already have non-null default values. Nullable<T> is a reference type, e.g. bool?.
• There is a property initializer, but it's initialized with null or null! (SuppressNullableWarningExpression) (e.g. public string Arg { get; set; } = null!;).
• If it's forced via attribute property Required (e.g. [CliArgument(Required = true)]).
• If it's forced via required modifier (e.g. public required string Opt { get; set; }). Note that for being able to use required modifier, if your target framework is below net7.0, you also need <LangVersion>11.0</LangVersion> tag (minimum) in your .csproj file (our source generator supplies the polyfills automatically as long as you set C# language version to 11).

An option/argument will be considered optional when

• There is no property initializer (e.g. public bool Opt { get; set; }) but the property type is a value type which already have non-null default value.
• There is a property initializer, and it's not initialized with null or null! (SuppressNullableWarningExpression) (e.g. public string Arg { get; set; } = "Default";).
• If it's forced via attribute property Required (e.g. [CliArgument(Required = false)]).

When you run,

or (note the double hyphen/dash which allows dotnet run to pass arguments to our actual application):

You see this result:

Supported types

Note that you can have a specific type (other than string) for a property which a CliOption or CliArgument attribute is applied to, for example these properties will be parsed and bound/populated automatically:

The following types for properties are supported:

• Booleans (flags) - If true or false is passed for an option having a bool argument, it is parsed and bound as expected. But an option whose argument type is bool doesn't require an argument to be specified. The presence of the option token on the command line, with no argument following it, results in a value of true.

• Enums - The values are bound by name, and the binding is case insensitive

• Common CLR types:

  • FileSystemInfo, FileInfo, DirectoryInfo
  • int, long, short, uint, ulong, ushort
  • double, float, decimal
  • byte, sbyte
  • DateTime, DateTimeOffset, TimeSpan, DateOnly, TimeOnly
  • Guid
  • Uri, IPAddress, IPEndPoint

• Any type with a public constructor or a static Parse method with a string parameter (other parameters, if any, should be optional) - These types can be bound/parsed automatically even if they are wrapped with Enumerable or Nullable type.

  [CliCommand] public class ArgumentConverterCliCommand { [CliOption] public ClassWithConstructor Opt { get; set; } [CliOption(AllowMultipleArgumentsPerToken = true)] public ClassWithConstructor[] OptArray { get; set; } [CliOption] public CustomStruct? OptNullable { get; set; } [CliOption] public IEnumerable<ClassWithConstructor> OptEnumerable { get; set; } [CliOption] public List<ClassWithConstructor> OptList { get; set; } [CliOption] public CustomList<ClassWithConstructor> OptCustomList { get; set; } [CliArgument] public IEnumerable<ClassWithParser> Arg { get; set; } } public class ClassWithConstructor { private readonly string value; public ClassWithConstructor(string value) { this.value = value; } public override string ToString() { return value; } } public class ClassWithParser { private string value; public override string ToString() { return value; } public static ClassWithParser Parse(string value) { var instance = new ClassWithParser(); instance.value = value; return instance; } } public struct CustomStruct { private readonly string value; public CustomStruct(string value) { this.value = value; } public override string ToString() { return value; } }

• Arrays, lists, collections:

  • Any type that implements IEnumerable<T> and has a public constructor with a IEnumerable<T> or IList<T> parameter (other parameters, if any, should be optional). CLR collection types already satisfy this condition.

  • If type is generic IEnumerable<T>, IList<T>, ICollection<T> interfaces itself, array T[] will be used to create an instance.

  • If type is non-generic IEnumerable, IList, ICollection interfaces itself, array string[] will be used to create an instance.

  [CliCommand] public class EnumerableCliCommand { [CliOption] public IEnumerable<int> OptEnumerable { get; set; } [CliOption] public List<string> OptList { get; set; } [CliOption(AllowMultipleArgumentsPerToken = true)] public FileAccess[] OptEnumArray { get; set; } [CliOption] public Collection<string> OptCollection { get; set; } [CliOption] public HashSet<string> OptHashSet { get; set; } [CliOption] public Queue<FileInfo> OptQueue { get; set; } [CliOption] public CustomList<string> OptCustomList { get; set; } [CliArgument] public IList ArgIList { get; set; } } public class CustomList<T> : List<T> { public CustomList(IEnumerable<T> items) : base(items) { } }

Validation

In [CliOption] and [CliArgument] attributes; ValidationRules property allows setting predefined validation rules such as

• CliValidationRules.ExistingFile
• CliValidationRules.NonExistingFile
• CliValidationRules.ExistingDirectory
• CliValidationRules.NonExistingDirectory
• CliValidationRules.ExistingFileOrDirectory
• CliValidationRules.NonExistingFileOrDirectory
• CliValidationRules.LegalPath
• CliValidationRules.LegalFileName
• CliValidationRules.LegalUri
• CliValidationRules.LegalUrl

Validation rules can be combined via using bitwise 'or' operator(| in C#).

ValidationPattern property allows setting a regular expression pattern for custom validation, and ValidationMessage property allows setting a custom error message to show when ValidationPattern does not match.

Completions

Apps that use System.CommandLine have built-in support for tab completion in certain shells. To enable it, the end user has to take a few steps once per shell. Once the user does this, tab completion is automatic for static values in your app, such as enum values or values you define by setting CliOptionAttribute.AllowedValues or CliArgumentAttribute.AllowedValues. You can also customize the tab completion by getting values dynamically at runtime.

In your command class, inherit ICliGetCompletions and implement GetCompletions method. This method will be called for every option and argument in your class. In the method, you should switch according to the property name which corresponds to the option or argument whose completions will be retrieved.

The dynamic tab completion list created by this code also appears in help output:

Dependency Injection

Commands can have injected dependencies, this is supported via Microsoft.Extensions.DependencyInjection package (version >= 2.1.1). In your project directory, via dotnet cli:

or in Visual Studio Package Manager Console:

When the source generator detects that your project has reference to Microsoft.Extensions.DependencyInjection, it will generate extension methods for supporting dependency injection. For example, you can now add your services with the extension method Cli.Ext.ConfigureServices:

Then let them be injected to your command class automatically by providing a constructor with the required services:

Other dependency injection containers (e.g. Autofac) are also supported via Microsoft.Extensions.DependencyInjection.Abstractions package (version >= 2.1.1). In your project directory, via dotnet cli:

or in Visual Studio Package Manager Console:

When the source generator detects that your project has reference to Microsoft.Extensions.DependencyInjection.Abstractions, it will generate extension methods for supporting custom service providers. For example, you can now set your custom service provider with the extension method Cli.Ext.SetServiceProvider:

Response files

A response file is a file that contains a set of tokens for a command-line app. Response files are a feature of System.CommandLine that is useful in two scenarios:

• To invoke a command-line app by specifying input that is longer than the character limit of the terminal.
• To invoke the same command repeatedly without retyping the whole line.

To use a response file, enter the file name prefixed by an @ sign wherever in the line you want to insert commands, options, and arguments. The .rsp file extension is a common convention, but you can use any file extension.

The following lines are equivalent:

Contents of sample1.rsp:

Contents of sample2.rsp:

Here are syntax rules that determine how the text in a response file is interpreted:

• Tokens are delimited by spaces. A line that contains Good morning! is treated as two tokens, Good and morning!.
• Multiple tokens enclosed in quotes are interpreted as a single token. A line that contains "Good morning!" is treated as one token, Good morning!.
• Any text between a # symbol and the end of the line is treated as a comment and ignored.
• Tokens prefixed with @ can reference additional response files.
• The response file can have multiple lines of text. The lines are concatenated and interpreted as a sequence of tokens.

Directives

System.CommandLine introduces a syntactic element called a directive. The [diagram] directive is an example. When you include [diagram] after the app's name, System.CommandLine displays a diagram of the parse result instead of invoking the command-line app:

Output:

The purpose of directives is to provide cross-cutting functionality that can apply across command-line apps. Because directives are syntactically distinct from the app's own syntax, they can provide functionality that applies across apps.

A directive must conform to the following syntax rules:

• It's a token on the command line that comes after the app's name but before any subcommands or options.
• It's enclosed in square brackets.
• It doesn't contain spaces.

An unrecognized directive is ignored without causing a parsing error.

A directive can include an argument, separated from the directive name by a colon (:).

You can define custom directives like below:

Currently only bool, string and string[] types are supported for [CliDirective] properties. Here is sample usage and output:

The following directives are built in:

The [diagram] directive

This directive can be enabled with CliSettings.EnableDiagramDirective.

Both users and developers may find it useful to see how an app will interpret a given input. One of the default features of a System.CommandLine app is the [diagram] directive, which lets you preview the result of parsing command input. For example:

In the preceding example:

• The command (myapp), its child options, and the arguments to those options are grouped using square brackets.
• For the option result [ --delay !<not-an-int> ], the ! indicates a parsing error. The value not-an-int for an int option can't be parsed to the expected type. The error is also flagged by ! in front of the command that contains the error-ed option: ![ myapp....
• For the option result *[ --fgcolor <White> ], the option wasn't specified on the command line, so the configured default was used. White is the effective value for this option. The asterisk indicates that the value is the default.
• ???--> points to input that wasn't matched to any of the app's commands or options.

The [suggest] directive

This directive is enabled by default and can be disabled with CliSettings.EnableSuggestDirective.

The [suggest] directive lets you search for commands when you don't know the exact command.

The [env] directive

This directive can be enabled with CliSettings.EnableEnvironmentVariablesDirective.

The [env] directive allows environment variables to be set from the command line during invocation:

Building

We provide some .cmd batch scripts in build folder for easier building:

Output results can be found in publish folder, for example:

Additional documentation

• DotMake Command-Line API docs
• Command-line syntax overview for System.CommandLine