Is this project dead?

[goldsam]

Is this project dead? There has only ever been beta prereleases and the last such was nearly a year and half ago. The examples don't compile against the most recent nuget.org release. I want to be excited about a project backed by the .Net Foundation, but this project seems like an idea that was never followed through on. . Is there any intent to make progress, or should I look at another option such as CommandLineParser?

[KalleOlaviNiemitalo]

The dotnet tool of .NET SDK heavily depends on this library.
I don't know what the actual reasons for the stall are but I hope the team is busy with the .NET 8 release and can resume work here after that.

[KalleOlaviNiemitalo]

The examples don't compile against the most recent nuget.org release.

Which examples are those? The example in Tutorial: Get started with System.CommandLine compiles OK against System.CommandLine 2.0.0-beta4.22272.1, which is the most recent nuget.org release.

(However, the first three options under "Test the app" do not work. The first option and the third option do not work because the shell searches for the scl executable along PATH, which does not include the current directory. The second option does not work because scl tries to read scl.runtimeconfig.json from the current directory but it's in the bin/Debug/net6.0 subdirectory.)

[goldsam]

I stand corrected. I was looking at the examples on the main branch. The examples do work for the released package version.

[jakenuts]

Is this project dead? There has only ever been beta prereleases and the last such was nearly a year and half ago. The examples don't compile against the most recent nuget.org release. I want to be excited about a project backed by the .Net Foundation, but this project seems like an idea that was never followed through on. . Is there any intent to make progress, or should I look at another option such as CommandLineParser?

The whole dotnet-suggest cli tab completion feature seems like it's gotta happen, though I'd prefer it in a low ceremony attribute based source-generated version.

[huoyaoyuan]

The productization of this repo is currently designed at dotnet/runtime repo (dotnet/runtime#84177).

[KalleOlaviNiemitalo]

Please post in this repo if more System.CommandLine issues are filed in https://github.com/dotnet/runtime/, so that prerelease users can subscribe to individual issues there rather than watch the whole repo.

• [API proposal]: System.CommandLine APIs runtime#68578
• System.CommandLine: Parsing runtime#84177
• System.CommandLine: Validation runtime#84178
• System.CommandLine: Completions runtime#84179

[goldsam]

@huoyaoyuan Are you talking about Microsoft.Extensions.Configuration.CommandLine (which is a completely different library)? I searched pretty thoroughly through the runtime repo, and I'm not seeing much there related to this repo/project. Could you please elaborate on what you mean by "productization of this repo"?

[huoyaoyuan]

Are you talking about Microsoft.Extensions.Configuration.CommandLine (which is a completely different library)?

No. I'm even unaware of such a library. The linked issue (dotnet/runtime#84177) is discussing API in System.CommandLine namespace.

I searched pretty thoroughly through the runtime repo, and I'm not seeing much there related to this repo/project.

There is no code there currently, but only some issues for API review, tagged in area-System.Console.

Could you please elaborate on what you mean by "productization of this repo"?

See #1882. In short,
Once we release as part of the System namespace, we will consider the API locked and will work to avoid further breaking changes. Since we will live with that API, we need to take the time now to get it right.

There are already pull requests tweaking namespace and type names like #2167.

[bhehe]

Following myself; I'm trying to advocate to use this library but the lack of a real release is a barrier for me at my employer.

[Zastai]

Agreed - I would much rather have had real releases at 0.1.0, 0.2.0, etc, indicating volatile API but as actual releases.

That API then gets locked down going towards 1.0.0 (whether it stays here or becomes part of the main runtime) makes perfect sense.

But it's hard to drive adoption with "scary" beta versions, which also means you're not getting feedback from a good chunk of developer's who can't try the current version in real-world scenarios.

[anthony-c-martin]

Agreed with the above. The other thing that makes this difficult is the lack of communication around an ETA.

We have been dying to use this library in https://github.com/Azure/bicep for over 2 years. For this duration, this project has felt like it's "almost ready", so we built our own super basic solution, and didn't put energy into investigating alternatives (because "we'll be able to switch soon"). In retrospect, if we knew we'd be waiting for this long, we'd have just picked an alternative and moved on. It's hard to know that we won't be waiting another 2 years at this point.

[calacayir]

See my project here:
https://github.com/dotmake-build/command-line

DotMake.CommandLine is a library which provides declarative syntax for System.CommandLine via attributes for easy, fast, strongly-typed (no reflection) usage. The library includes includes a source generator which automagically converts your classes to CLI commands and properties to CLI options or CLI arguments. Supports trimming and AOT compilation !

[lloydjatkinson]

Now that .NET 8 is out, can some time be given to this API? If not, I guess using Microsoft.Extensions.Configuration.CommandLine is a mostly OK option.

[mburumaxwell]

I believe Microsoft.Extensions.Configuration.CommandLine works for simple CLI applications where commands/sub-commands and other concepts are either not required or are simple enough to be written in the same app.
For other scenarios, either use the nightly builds (with breaking changes) or use SpectreConsole which has many more features and is stable.

[lloydjatkinson]

I believe Microsoft.Extensions.Configuration.CommandLine works for simple CLI applications where commands/sub-commands and other concepts are either not required or are simple enough to be written in the same app. For other scenarios, either use the nightly builds (with breaking changes) or use SpectreConsole which has many more features and is stable.

You are right. It's strange that System.CommandLine appears to be being neglected. Entire new projects have been created and realised in the same time span, like Aspire...

[timker]

Hoping they find time to improve System.Commandline, but other options include (in no particular order):

• https://github.com/spectreconsole/spectre.console
• https://github.com/mayuki/Cocona
• https://github.com/commandlineparser/commandline

[BenjaminMichaelis]

Hoping they find time to improve System.Commandline, but other options include (in no particular order):

This project is actively being worked on; see #2338

[aetos382]

Another advanced alternative: https://github.com/Cysharp/ConsoleAppFramework