Latest Version

As you can see, Version 2.0 is publicly available as an alpha. This is not just a matter of stability, it also means that the API is subject to change until it is promoted beyond pre-release status.

From a git repository perspective, 2.0 alpha lives in the master branch, while the latest stable branch can be found in stable-1.9.71.2; previous versions are tagged.

Public branches may exist as part of development, but are normally of collaborator's interest only.

I recommend that you refer to the unit tests of the Parser class to get started.

Get it

I recommend cloning the repository since I will not push the alpha branch to NuGet very often. Each time I publish the alpha, I'll warn Twitter followers.

PM> Install-Package CommandLineParser -Pre

I will sometimes hold off on listing the latest alpha versions on NuGet that I mention in tweets, so take note of the version and install it via the Package Manager Console. For example, to install 2.0.9-alpha:

PM> Install-Package CommandLineParser -Version 2.0.9-alpha

Overview

The package doesn't have any dependencies. The reference to FSharp.Core.dll is only required at compile time or at runtime for F# projects (which contain this reference by default).

The Parser is activated from the Parser class, defined in the CommandLine namespace. I suggest that you use the pre-configured Default singleton, and only construct your own instance when really required.

using CommandLine;

// (1) default singleton
var result = Parser.Default.ParseArguments<Options>(args);

// (2) build and configure instance
var parser = new Parser(with => with.EnableDashDash = true);
var result = parser.ParseArguments<Options>(args)

In the latter case the Parser(Action<ParserSettings>) constructor was called to configure the parser via the ParserSettings instance.

The CommandLine.Text namespace contains everything you need to create a user friendly help screen. This is done in a completely automated manner if ParserSettings.HelpWriter is set.

The default instance Parser.Default initializes with ParserSettings.HelpWriter set to Console.Error.

These features are completely optional, so you can take advantage of and customize features to any degree you like.

Options

Version 2.0 uses only two attributes to describe option syntax: Option and Value·

Option works much like in previous versions, but it can be applied to scalar or sequence values (IEnumerable<T>).

When applied to sequences you can also define Min and Max properties to specify a range of values.

Value resembles ValueOption and ValueList from previous versions. Akin the new Option attribute, they can be applied to sequences, and now support the Required property too.

[Value] Attribute

Values are partitioned by index. For example:

class Options {
  [Value(0)]
  public int IntValue { get; set; }

  [Value(1, Min=1, Max=3)]
  public IEnumerable<string> StringSeq { get; set; }

  [Value(2)]
  public DoubleValue { get; set; }
}

So long as you supply values, they will be set to corresponding properties:

$ app 10 str1 str2 str3 1.1

If you omit Min and Max constraints, all available values will be captured by the sequence. There's no point defining a Value attribute with a higher index than that of a sequence Value which lacks a Max range constraint:

class Options {
  [Value(0)]
  public int IntValue { get; set; }

  [Value(1)]
  public IEnumerable<string> StringSeq { get; set; }

  // all values captured by previous specifications,
  // this property will never receive a value
  [Value(2)]
  public DoubleValue { get; set; }
}

[Option] Attribute

Omitting an option name is perfectly acceptable. In such a case, the long name will be inferred from the member's name.

class Options {
  [Option]
  public string UserId { get; set; }
}

This allows:

$ app --userid=root

Option attribute also supports a Separator property to mimic the deprecated OptionList behavior when applied to sequences.

class Options {
  [Option('t', Separator=':')]
  public IEnumerable<string> Types { get; set; }
}

This allows:

$ app -t int:long:string

Capturing Sequences

As mentioned above, you can apply both new attributes to IEnumerable<T> (where T is a CLR built-in data type such as string, int, etc).

You can also specify a Min constraint or a Max constraint alone: this means you only want check for minimum or maximum number of elements. Breaking a constraint will cause parsing to fail.

You could overlay Min=1 with Required=true but there's no point in doing so because the parser will check Required before the Min constraint. In this case you should favour Min=1 whilst Min=1, Max=1 should be avoided (even though they will behave as expected) in favour of Required=true.

Parsing

Parsing is as easy as writing one line of code:

var result = Parser.Default.ParseArguments<Options>(args);

The above is a basic usage scenario (without verbs) utilizing the default pre-built instance to parse input arguments and using the rules specified in Options (as described above).

The result variable (defined here using implicit typing) is of type ParserResult<T>, or more specifically ParserResult<Options>.

If parsing succeeds, you'll get a the derived Parsed<T> type that exposes an instance of T through its Value property.

If parsing fails, you'll get a derived NotParsed<T> type with errors present in Errors sequence.

Even though it's possible to examine the Errors sequence, it's recommended to quit with an appropriate error code. The library help subsystem will print out usage and error descriptions automatically. The parser default instance is configured to output this text to Console.Error.

This small hierarchy is modelled like an F# discriminated union. You don't need a type cast to discover which derived type you received, you can simply examine the Tag property.

Two convenient extension methods are provided to help you access values:

var result = Parser.Default.ParseArguments<Options>(args)
  .WithParsed(options => ...) // options is an instance of Options type
  .WithNotParsed(errors => ...) // errors is an sequence of type IEnumerable<Error>

These methods accept a System.Action lambda, but if you prefer another approach, you can transform the parser result into any other value using Return(...):

// you can directly turn the result into an exit code for example
int Main(string[] args) {
  return Parser.Default.ParseArguments<Options>(args)
    .Return(
      options => RunAndReturnExitCode(options),
      _ => 1);
}

Verbs

To take advantage of verb commands simply an option class for each verb decorated with [Verb] attribute:

[Verb("add", HelpText = "Add file contents to the index.")]
class AddOptions { //normal options here
}
[Verb("commit", HelpText = "Record changes to the repository.")]
class CommitOptions { //normal options here
}
[Verb("clone", HelpText = "Clone a repository into a new directory.")]
class CloneOptions { //normal options here
}

A this point you have to use a proper ParserArguments<T1, T2...> overload that accepts more than one type (without using the overload with variadic arguments, the library define versions with up to 16 type parameters):

var result = Parser.Default.ParseArguments<AddOptions, CommitOptions, CloneOptions>(args);

In this case the T Value property of ParserResult<T> will be object but will contain the proper instance if parsing succeeds or NullInstance if fails.

The only change with normal parsing is the requirement to query the Parsed<object>.Value property and invoke the application logic written to handle a specific verb.

An helper extension method is provided to simplify this task:

Parser.Default.ParseArguments<AddOptions, CommitOptions, CloneOptions>(args)
  .WithParsed<AddOptions>(opts => ...)
  .WithParsed<CommitOptions>(opts => ...)
  .WithParsed<CloneOptions>(opts => ...)
  .WithNotParsed(errs => ...)

Coherently with ParseArguments<T1, T2, ...>() overloads used for verbs, you can take advantage also of Return<T1, T2, ...>(). Like in the sample with a single target instance, here we turn the parsed verb into an exit code:

int Main(string[] args) {
  return Parser.Default.ParseArguments<AddOptions, CommitOptions, CloneOptions>(args)
    .Return(
      (AddOptions opts) => RunAddAndReturnExitCode(opts),
      (CommitOptions opts) => RunCommitAndReturnExitCode(opts),
      (CloneOptions opts) => RunCloneAndReturnExitCode(opts),
      errs => 1);
}

In this scenario the parser supplies you an additional help verb that allows:

$ app help clone

In this way application users can display specific verb command help screen.

$ app help

Or will display an help screen for available verbs.

Immutable Target

If you develop according to functional programming, you probably won't define a mutable type like the ones presented in samples.

You're free to define an immutable type:

class Options {
  private readonly IEnumerable<string> files;
  private readonly bool verbose;
  private readonly long offset;

  public Options(IEnumerable<string> files, bool verbose, long offset) {
    this.files = files;
    this.verbose = verbose;
    this.offset = offset;
  }

  [Option]
  public IEnumerable<string> Files { get { return files; } }

  [Option]
  public bool Verbose { get { return verbose; } }

  [Option]
  public long Offset { get { return offset; } ]
}

The parser will rank this class as immutable by the absence of public property setters and fields.

This is the same feature that allow you to parse against an F# record:

type options = {
  [<Option>] files : seq<string>;
  [<Option>] verbose : bool;
  [<Option>] offset : option int64;
}

As you can see the options.offset record member was defined as option<int64> since the library has full support for option<'a> (full CLR name type name Microsoft.FSharp.Core.FSharpOption<T>).

Help Screen

One of strengths of this library lies in the ability to automatically generate an help screen for the end user. This is formatted using common conventions of command line applications through the use of metadata defined in Option, Value and Verb attributes.

The library supplies a built-in --help switch that halts processing and displays the help screen. The help screen is also displayed when parsing process fails, along with clear and explicit description of every error encountered.

When using verbs, the library supplies a built-in help verb. It displays the verbs index (with the list of all verbs) or, when invoked with another verb as argument, it will display the specific help screen of the requested verb.

The parser can also print version information (taken from assembly level attributes) using the built-in --version switch or the built-in version verb.

If you use the pre-built singleton, this is configured to print the help screen to Console.Error. You can change this setting, creating and configuring a Parser instance by your own:

// As you can see, it's a really simple:
var parser = new Parser(config => config.HelpWriter = Console.Out);

There's a great difference between 2.0 and previous stable(s), since the new version is the only that can handle and generate help for Value positional options. To avoid the standard naming of value pos. N (where N is ValueAttribute.Index), you can use the new MetaName property.

If you want to manage the help screen by our own, just leave ParserSettings.HelpWriter not set and, when parsing fails, build and print your custom help screen. Also in such case, you're not forced to do everything from scratch: you can use the same types employed by the library that live in CommandLine.Text namespace.

See also Usage attribute paragraph.

Unparsing

You can transform back a parsed instance or a freshly created one into a string with command line arguments. Assuming this options class:

class Options {
  [Option('i','input')] public string InputFile { get; set; }
  [Option('w')] public IEnumerable<string> Words { get; set; }
}

And building up this instance:

var options = new Options { InputFile = "infile.csv", Words = new[] { "these", "are", "words" } };

You can format a command line string invoking:

var arguments = CommandLine.Parser.Default.FormatCommandLine(options);

Output will be as above:

--input infile.csv -w these are words

In this first version of such feature the output is not customizable, but follows the above algorithm:

• options before values and sorted by name
• values sorted by index
• long name preferred over short name
• basic syntax: name[space]value
• strings with spaces and double quotes are correctly formatted and escaped

The feature will work with immutable instances and already supports F# 'T option type. If the instance contains the Verb attribute, its name will be prepended before options.

If you need more control over output, you can use the following overload:

class UnParserSettings {
  // Short or long name?
  bool PreferShortName { get; set; }
  // Group defined bool switches?
  bool GroupSwitches { get; set; }
  // Use equal sign with long name when possible?
  bool UseEqualToken { get; set; }
}

string FormatCommandLine<T>(T options, Action<UnParserSettings> configuration)

Example:

var arguments = CommandLine.Parser.Default.FormatCommandLine(options, config => config.GroupSwitches = true);

[Usage] Attribute

The Usage attribute is a new 2.0.x feature that allows you to format application usage examples with easy. You've to mark a static property of your instance or verb instance class and supply metadata as in the snippet above.

class Options {
// Normal options here.

[Usage(ApplicationAlias = "yourapp")]
public static IEnumerable<Example> Examples {
  get {
    yield return new Example("Normal scenario", new Options { InputFile = "file.bin", OutputFile = "out.bin" });
    yield return new Example("Logging warnings", UnParserSettings.WithGroupSwitchesOnly() , new Options { InputFile = "file.bin", LogWarning = true });
    yield return new Example("Logging errors", new[] { UnParserSettings.WithGroupSwitchesOnly(), UnParserSettings.WithUseEqualTokenOnly() }, new Options { InputFile = "file.bin", LogError = true });
  }
}

The real constraints are visibility, data type and the need to define the property as static; anyway I'll suggest you to name such property Examples as standard.

The Example class is used to supply metadata to HelpText.AutoBuild() that will add a properly formatted USAGE: section to your help screen.

class Example {
  public Example(
    string helpText, // description of example
    IEnumerable<UnParserSettings> formatStyles, // different styles of generated command line
    object sample // instance with sample data
  )
  // ...omissis...
}

The important thing to know is that UnParserSettings is exactly the same type accepted by Parser.FormatCommandLine<T>(T options, Action<UnParserSettings>); since this API is the same used internally to generate part of the example command line.

UnParserSettings.WithGroupSwitchesOnly() and UnParserSettings.WithUseEqualTokenOnly() are just factory methods to simplify the creation of an instance with the property in the name set to true.

Further Notes

This section is a reduced version of the full wiki, still dedicated to latest stable. Sometimes old information can be adapted to 2.0.x, but if not feel free to ask by opening an issue.