Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://github.com/fclp/fluent-command-line-parser/wiki/Roadmap below:

Roadmap · fclp/fluent-command-line-parser Wiki · GitHub

• .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

• 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

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

• 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);

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));
}

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");

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>.

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);
   }
}

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.

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.

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.

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.

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4