ConsoleAppFramework v3 — command line tool framework for .NET Core
I’ve renewed ConsoleAppFramework, a framework for easily creating CLI applications and many batches in C#.
- github — Cysharp/ConsoleAppFramework
The concept of a CLI framework on top of Generic Host, the basic structure, remains unchanged.
The method definitions become command line arguments, and help is generated automatically, as well as settings of loggers and DIs, and loading and binding of options in the Generic Host (also used in ASP.NET Core, etc.), so you can do detailed configuration with it. Since the foundation is the same, it can be shared with ASP.NET Core and others.
The simplest example would look like this
v3’s new feature is
- Strictly argument parser
- Show default commands(help, version) on help command
- Automatic command definitions assign to
- Filter(Middleware) extension
dotnet already has standard System.CommandLine package. However System.CommandLine is low-level API, it requires to create binding manually., You’ll need a lot of boilerplate lines. If you compare it to ASP.NET Core, System.CommandLine is Core only and you need to create your own Middleware. ConsoleAppFramework is ASP.NET Core MVC.
When parsing arguments, the default is to ignore the number of `-`, For example, golang commands are the same thing, just like `-o`, `-output`.
I’ve added an option to strictly distinguish between
— like the dotnet command.
The help which defaulted to -m, — message <String> is changed to -m, — message. If you specify -message, an error message saying the name does not match will appear.
Also, the version, help command is now shown by default. This is also removed by setting the option ShowDefaultCommand = false (the command is still there).
automatically class/method command routing
When you create batches for a project, you need to create dozens, sometimes hundreds, of batches. The ConsoleAppFramework provides a feature that allows you to route commands automatically, so you can easily create command. Just as the MVC framework uses class/method to route URLs, it automatically creates a sub-command hierarchy called class method for you.
Like ASP.NET Core and Cysharp/MagicOnion, filters can now be used to extend the pre- and post-execution. The implementation is asynchronous style, inheriting from ConsoleAppFilter and executing await next.
Filters can be given on a global (called by all methods), class or method basis.
For example, ConsoleAppFramework does not prevent double startup but if create filter, can do.
It has a good balance of simplicity and functionality. You can’t adjust it to the detail, so you need to divide it up, but most use cases should be satisfied.
Automatic command definitions are useful when creating large numbers of batches. Another advantage is that you can manage a large number of batches with a single C# project. It’s confusing to manage them in a file unit, but they can be organized in csproj, and can be shared with other projects by using logic methods. Also, by using filters, you can promote commonality in pre-processing and post-processing.
In the case of a batch app as part of a larger project, it’s also important to be able to easily read the DB paths and other data defined in the configuration, such as ASP.NET Core, as it’s the same generic host.
If you need logger performance, you can use Cysharp/ZLogger, because ZLogger is also built on top of Microsoft.Extensions.Logging, which is based on a generic host The ConsoleAppFramework is smooth to use.
Please try, new more powerful ConsoleAppFramework.