Switch from CommandLineParser and McMaster.Extensions.CommandLineUtils to System.CommandLine

[adamsitnik]

As of today, we are using:

• CommandLineParser to parse arguments for BenchmarkSwitcher
• McMaster.Extensions.CommandLineUtils to parse the arguments for our first global tool (BenchmarkDotNet as global tool #1006)

Having two dependencies to parse command line arguments is not good.

I think that we should switch to System.CommandLine if possible (project)

System.CommandLine is the future of parsing command line arguments in .NET. It's not a MS-only project, it has been built together by the community and MS based on experiences from many existing command line parsing projects.

I have seen a 1h internal demo at MS and to tell the long story short it has everything that CommandLineParser and McMaster.Extensions.CommandLineUtils have and a lot of more cool features. You can read more about the motivations for it here

What this task requires:

1. Make sure that System.CommandLine supports everything that CommandLineParser gives us as of today:
   • parsing simple arguments (1 value)
   • parsing more complex arguments (IEnumerable<string>)
   • parsing arguments with aliases (example: -i --inprocess)
   • help with samples
2. Making sure that System.CommandLine supports everything that McMaster.Extensions.CommandLineUtils gives us as of today for the global tool

The global tool was merged to https://github.com/dotnet/BenchmarkDotNet/tree/tools branch. So a person working on this task would have to create branch out of tools branch.

If System.CommandLine meets all our needs, then I can talk with @KathleenDollard about publishing a signed package to Nuget.org and we can switch (dotnet/command-line-api#356)

@wojtpl2 perhaps you would be interested in this issue?

[WojciechNagorski]

@adamsitnik I would like to do this but I think System.CommandLine is still not ready yet. There is more information dotnet/command-line-api#345 (comment).

@KathleenDollard made great PR dotnet/command-line-api#363 but it is not finished yet. This approache for me it will be the best option. Something similar to CommandLineParser.

Currently we can use only core APIs directly from System.CommandLine like here: https://github.com/dotnet/command-line-api/wiki/Your-first-app-with-System.CommandLine
Of course I can use it, but keep in mind that this code will change in the future.

[WojciechNagorski]

@adamsitnik If we want to use System.CommandLine we need published package to Nuget.org or at least a preview version.

[WojciechNagorski]

System.CommandLine supports:

• parsing simple arguments (1 value)
• parsing more complex arguments (IEnumerable<string>)
• parsing arguments with aliases (example: -i --inprocess)
• command with arguments.

I don't know yet:

• help with samples

I'll create PR next week.

some preview:

C:\Users\wnagorsx\source\repos\ConsoleApp7\ConsoleApp7
λ dotnet run -- --job Dry -m 1
Unrecognized command or argument '1'

ConsoleApp7:
  BDN :)

Usage:
  ConsoleApp7 [options]

Options:
  -j, --job          Dry/Short/Medium/Long or Default
  -r, --runtimes     Full target framework moniker for .NET Core and .NET. For Mono just 'Mono', for CoreRT just 'CoreRT'. First one will be marked as baseline!
  -e, --exporters    GitHub/StackOverflow/RPlot/CSV/JSON/HTML/XML
  -m, --memory       Prints memory statistics
  --version          Display version information

[WojciechNagorski]

I found one problem in System.CommandLine. It supports multiple value, but in different way. You always have to repeat alias of parameter for each value like this:
--runtime net472 --runtime netcoreapp2.1

I created issue in System.CommandLine dotnet/command-line-api#383

[WojciechNagorski]

My PR dotnet/command-line-api#384 to System.CommandLine is marged. Now we can switch to System.CommandLine.

[WojciechNagorski]

I created second PR dotnet/command-line-api#385

[adamsitnik]

@wojtpl2 awesome! great job!