History and purpose: how this is project came to be, and what it's for

[natemcmaster]

git mv {Microsoft => McMaster}.Extensions.CommandLineUtils

History

The ASP.NET Core team is in the business of producing a web framework, and not in producing .NET libraries in general. In the early days of what later became ASP.NET Core, Microsoft.Extensions.CommandLineUtils was created as a requirement of producing dnx and ASP.NET vNext. It was never intended to be the Microsoft-official way to write command line apps. After later refactoring of the architecture of dnx into dotnet, and reassignments of resources, the ASP.NET Core team no longer maintains much command-line code, so they decided to stop active development on their CommandLineUtils library. See dotnet/extensions#257.

What this is

Hence, I've forked the project. This project will maintain and improve upon the 1.0 and 1.1 versions of the library.

Fork is the operative word here. Not branch, not update, not replace.

Goals

• Patches, minor bug fixes to API originally in Microsoft.Extensions.CommandLineUtils (thank you Apache 2.0 license)
• Improvements. Include more non-breaking changes and new API that make it easier to write command line applications.
• Maintenance. Keeping up with the continual shift in .NET. PCL => dnxcore50 => dotnet5.1 => netstandard. There has been lots of churn, and I expect there will continue to be. I'll attempt to keep pace.

Non-goal

• This is unofficial. Don't expect Microsoft-official support.
• Replacing Microsoft.Extensions.CommandLineUtils. Someone at Microsoft may attempt to restart active dev work on this. If so, bravo. There will be welcome to merge this code, which will also use the Apache license.
• Competing for an official System.* namespace. Although the .NET team has been drafting System.CommandLine for a long time, it is not yet generally available and has no set roadmap.

Future

This repo is open to community contributions under the Apache 2.0 License. Please read the contributing guidelines, and tag me @natemcmaster in the pull-request.

Cheers,
Nate. 🍻

[ebekker]

Just curious, have you looked at a couple other efforts that are trying to build out standard CLI parsing for .NET? Some of them are even being run as MS projects? Or do you just find you like the M.E.CLU approach the best?

[natemcmaster]

Yeah, there are plenty of libraries already available for command-line parsing, including a draft of official support, aka System.CommandLine. This project started not as an attempt to replace those, but rather it was about making a community-driven fork of a library that has seen lots of adoption and that MS decided to drop. @ebekker did you have other efforts in mind?

[ebekker]

Well I'm one of those that started to adopt M.E.CLU -- when I saw the Microsoft.Extensions namespace I assumed it was an endorsement of sorts, similar to how .Logging, .Configuration and .DependencyInjection are being treated in the .NET Core space.

But even before the announcement was made to discontinue support, I had already started looking at what everyone else was doing in the CLI parsing space, and I found a few that I started to play with:

• https://github.com/gsscoder/commandline
• https://github.com/dotnet/CliCommandLineParser
• https://github.com/dotnet/corefxlab/tree/master/src/System.CommandLine
• https://github.com/dotnet/buildtools/blob/master/src/common/CommandLine.cs

I even tried to get some clarity on this from the powers that be but that only gave me more options :-)

Anyway, just curious what your take was on the landscape -- if you had played with others and actually settled on/preferred the model of M.E.CLU?

[ebekker]

BTW, when I did initially decide to adopt M.E.CLU, while I like the overall API, I'm very much a model-driven and declarative-approach kinda guy, so I started to build such an optional layer atop CLU: https://github.com/zyborg/Zyborg.CLI

I've since stopped working on it, but if you pursue this reincarnation, I may get re-inspired...

[shaggygi]

If possible, I would like to see more effort put into the API in CoreFxLab.

https://github.com/dotnet/corefxlab/blob/master/src/System.CommandLine/README.md

[ebekker]

@shaggygi -- maybe it's just me, but I wasn't too happy with the very explicit and mechanical approach they took, it didn't seem any better than what I used with Mono.Options (NDesk) for many, many years before .NET Core came around.

[natemcmaster]

I'd be very interested to see an official response to dotnet/corefxlab#1311.

Anyway, just curious what your take was on the landscape

My understanding of the landscape: https://imgs.xkcd.com/comics/standards.png

This is an important piece of System.CommandLine's readme:

The purpose of this library is to make command line tools first class by providing a command line parser. We've already made an attempt in 2009 but that wasn't a design we (or the community) was happy with.

I'm fairly new to .NET (i.e. only started working with it full time a few years ago), so I'm sure there is history that I've missed here. But it seems even the .NET team has tried to design a CLI parsing API, and found it difficult to satisfy everyone. M.E.CLU isn't exempt from this either.

That said, I'm hoping to carry on the work of building a solid CLI parsing command line. Maybe I should also write a roadmap...

[ebekker]

I suspect what you see in 1311 is as official as it will get.

[shaggygi]

@natemcmaster funny image 😄

I honestly don't care which API is the winner. I just hope for one that gets some good features and backing from MS and the community. I just thought the one on CoreFxLabs would be the one that got the most love and eventually made it over to CoreFx like some of the other experimental APIs.

I'll keep an eye on your progress, as well.

Thanks