Roadmap

v2.0 WIP

• .NET Standard 2.0 nuget package (existing package still targets .NET 3.5 Client Framework)
• Issue 82 - Git style commands - Commands with independent options such as:

app.exe add "c:\file1.txt" "c:\file2.txt" --verbose --ignore-errors
app.exe rem "c:\file1.txt" "c:\file2.txt" --verbose

• Issue 89 - UseForOrphanArguments

app.exe "c:\my folder\datafile.dat" will result in fclp.Object.File == "c:\\my folder\datafile.dat

var fclp = new FluentCommandLineParser<Args>();

fclp.Setup(arg => arg.File)`
     `.As('f', "file")`
     `.UseForOrphanArguments(); // if no option specified then values are bound to this option

• Issue 64 - Custom Argument Object Creation

var fclp = new FluentCommandLineParser<StartupArguments>(() => new StartupArguments());

• Issue 39 - DisableShortOptions

var fclp = new FluentCommandLineParser().DisableShortOptions();

• Issue 53 - Custom Formater not passing default parameter value

/// <summary>
/// Gets the default value set for this options
/// </summary>
/// <returns>The default value set or <c>null</c> if no value has been set</returns>
object GetDefaultValue();

• Issue 42 - UseOwnOptionPrefix

var fclp = new FluentCommandLineParser().UseOwnOptionPrefix("-", "--");

• Issue 71 - add option execute sequence support (thanks @aspark)

var parser = new Fclp.FluentCommandLineParser() { ParseSequence = FluentCommandLineParseSequence.SameAsOptions };

• Issue 72 - TimeSpan option parser (thanks @LazyTarget)
• Issue 60 - Replace AdditionalOptionsFound with AdditionalOptions

Breaking Api Changes (!!)

• ICommandLineParserResult.AdditionalOptionsFound property has been replaced with ICommandLineParserResult.AdditionalOptions which contains the actual ParsedOption object instead of strings.

Removed old marked obsolete code completely

• FluentCommandLineBuilder class
• FluentCommandLineBuilder<TType> class
• FluentCommandLineParser.Setup<T>(string shortOption, string longOption) method

v1.4.3

• Issue 40 - Support long/int64
• Issue 43 - Nullable enum support

v1.4.2

• Fixes Issue 36 - Please add support for Nullable

• Added support for boolean on/off

app.exe --boolean on   // boolean is set to true
app.exe --boolean off  // boolean is set to false

• Added support for parsing URI type

app.exe --uri https://github.com/fclp/fluent-command-line-parser

Uri actual;

var parser = new FluentCommandLineParser();

parser.Setup<Uri>('u', "uri")
      .Callback(val => actual = val);

parser.Parse(args);

Assert.IsNotNull(actual);
Assert.AreEqual("https://github.com/fclp/fluent-command-line-parser", actual.AbsoluteUri);

v1.4

Enum Flag Support

With thanks to @alexruzzarin enum flags are now supported.

[Flags]
enum Direction
{
	North = 1,
	East = 2,
	South = 4,
	West = 8,
}

dosomething.exe --direction South East
dosomething.exe --direction 4 2

static void Main(string[] args)
{
  var p = new FluentCommandLineParser();

  Direction direction;

  p.Setup<Direction>("direction")
   .Callback(d => direction= d);

  p.Parse(args);

  Assert.IsFalse(direction.HasFlag(Direction.North));
  Assert.IsTrue(direction.HasFlag(Direction.East));
  Assert.IsTrue(direction.HasFlag(Direction.South));
  Assert.IsFalse(direction.HasFlag(Direction.West));
}

v1.3

Enum Support

Thanks to the initial work from @pchalamet enums are now supported out of the box.

public enum Direction
{
	Left = 0,
	Right = 1,
	Up = 3,
	Down = 4
}

p.Setup<Direction>('d', "direction")
 .Callback(d => direction = d);

To specify 'Right' direction either the text can be provided or the enum integer.

dosomething.exe --direction Right
dosomething.exe --direction 1

You can also collect multiple Enum values into a List

List<Direction> direction;

p.Setup<List<Direction>>('d', "direction")
 .Callback(d => direction = d);

For example, specifiying 'Right' and 'Up' values

dosomething.exe --direction Right Up
dosomething.exe --direction 1 3

And the generic FluentCommandLineParser (previously known as FluentCommandLineBuilder) also supports enums.

public class Args
{
   public Direction Direction { get;set; }
   public List<Direction> Directions { get;set; }
}

var p = new FluentCommandLineParser<Args>();

p.Setup(args => args.Direction)
 .As('d', "direction");

p.Setup(args => args.Directions)
 .As("directions");

Api Changes (!!)

FluentCommandLineBuilder<T> has been renamed to FluentCommandLineParser<T>. FluentCommandLineBuilder has been made obsolete but will not cause a compiler error in this release. Please replace any usage of with FluentCommandLineParser<T>.

v1.2

Fluent Command Line Builder

Instead of assigning parsed values to variables you can use the Fluent Command Line Builder to automatically create a defined object type and setup individual Options for each strongly-typed property. Because the builder is simply a wrapper around the parser you can still use the Fluent Command Line Parser Api to define the behaviour for each Option.

The Fluent Command Line Builder can build a type and populate the properties with parsed values such as in the following example:

public class ApplicationArguments
{
   public int RecordId { get; set; }
   public bool Silent { get; set; }
   public string NewValue { get; set; }
}

static void Main(string[] args)
{
   // create a builder for the ApplicationArguments type
   var b = new FluentCommandLineBuilder<ApplicationArguments>();

   // specify which property the value will be assigned too.
   b.Setup(arg => arg.RecordId)
    .As('r', "record") // define the short and long option name
    .Required(); // using the standard fluent Api to declare this Option as required.

   b.Setup(arg => arg.NewValue)
    .As('v', "value")
    .Required();

   b.Setup(arg => arg.Silent)
    .As('s', "silent")
    .SetDefault(false); // use the standard fluent Api to define a default value if non is specified in the arguments

   var result = b.Parse(args);

   if(result.HasErrors == false)
   {
      // use the instantiated ApplicationArguments object from the Object property on the builder.
      application.Run(b.Object);
   }
}

Setup Option by specifying long name only

In v1.1 and earlier, to setup an Option a short name must always be supplied. This has now been changed so Options with just long names can also be created.

Better Option Validation

The validation invoked when setting up new Options has been re-factored and improved. More meaningful error message will now be thrown when called with invalid data.

Functional Changes (!)

Some functional changes have been made which may impact existing behaviour.

A InvalidOptionNameException is now thrown when setting up an Option if:

• A specified long Option name is a single char in length.
• A specified long Option name contains : or = characters anywhere within it.

Short, long and help Options are now case sensitive. This means that -s and -S are considered different, also long Options --long and --LONG are considered different. This behaviour can be disabled and case ignored by doing parser.IsCaseSensitive = false.

Breaking Api Changes (!!)

Changes have been kept to a minimal with the following changes made:

• Setup<T>(string, string) has been made obsolete, being replaced instead with Setup<T>(char, string). This is to better reflect through the Api that short Options should be a single character only.
• Setup<T>(string) is no longer used to setup an Option with only a short name. Instead it is used to setup an Option with only a long name. This will initially result in an InvalidOptionNameException raised when the method is invoked as long names must now be longer than a single character in length. If you require to setup an option with a short name only you should use the Setup<T>(char) overload instead.