This is a light-weight dotnet standard 2.1 library, that you can add to your console applications, and create your command line application easily.
- Install package from NuGet
- Create an application by extending the class
CommandLineApplication
. - Add each Command you need, by creating a class which implements
ICommand
. You can also extendCommandBase
instead, so you can make use of some pre implemented and helper methods in it. - Introduce each command to your application by using the
SubCommand
attribute. ex:
[Subcommands(typeof(FirstCommand),typeof(SecondCommand))]
public class ExampleApplication:CommandLineApplication{
...
}
- In your main application entry, instantiate your application and start it.
Please checkout the Example project in repository, for a quick start
- Simple to use
- Nested commands (Each command can have its own sub-commands and so on...)
- Auto generated Help command for each command
- Can be started as a regular console application OR interactively
- Supports Dependency Injection
Each command, can have as many sub commands as needed the same way you added your commands to your application class. For a command to have some sub-commands, you would use Subcommands
attribute on parent command and introduce it's child commands.
Arguments would be child commands that their job is to acquire a value from string[] args
for it's parent command. the Context
object would be the carrie of this data. the argument-command, processes the args[] object, and saves the result in context. and when parent command gets executed, it can check the context object for it's arguments.
public void Set<T>(string key, T value)
- This method will store a value into the context
public T Get<T>(string key, T defaultValue)
- This method would be used to provide previously stored data from the context.
ApplicationExit
- Setting this property inside any command, would cause the chain of commands to be terminated.
InteractiveExit
- Setting this property inside any command, would close the application when is executed interactively.
- Usually there is no need to set this manually. When you start your application interactively, and exit command is already added to your commands that would set this property when called. So without any extra coding, you can exit the interactive application just by typing exit.
If you implement ICommand
class, then you would have to implement Name
and Description
properties. On the other hand, by extending the CommandBase
class, by default these properties would be set from the class name of the command. but you still are able to override these properties.
There are ApplicationTitle
and ApplicationDescription
properties in CommandLineApplication class that you can set on instance you create or in the driven class's constructor. These values would be printed when You start your application.
There is an Output
property in Application command which determines the default output method for console application to print out it's output. The Action<string>
set into this property, would be delivered to all executing commands to use.
If you extend CommandBase
class, it's already handled and you can use Output("some-string")
inside your driven class (your command) to write on output.
And if you implemented the ICommand
interface, this output delegate would be delivered to your code when SetOutput(..)
method of your command is called before execution.
In a similar way to Output
property, you can set Logger
property of your application to make use of your logger of interest. This property is of type ILogger
(microsoft's) and can accept any implementation.
NOTE: Using Logger or default Output for printing information towards the user, is up to the developers decision. But the recommended usage would be to use Output for printing execution results and information. And Use logger only for debugging and development logs.
To make use of any kind of dependency injection, you just need to provide a
facade of your di/ioc resolver by implementing IResolver
. Then you can
connect your di/ioc by setting the Application's Resolver property to an instance
of your IResolver
.
by doing so, you can deliver your registered services to your commands by conventional constructor injection easily.
NOTE: In most of ioc/di implementations, you need to register any thing which at some point is supposed to be resolved. since commands with constructor parameters are also being resolved using your resolver, it's so important to REMEMBER TO REGISTER COMMANDS ON YOUR DI REGISTRY. other-wise your commands would not be resolved with resolver, also since they have constructor parameters, they would not be instantiated without a resolver and therefore they will not work.
NOTE: If you use dotnet's builtin di system, you can just simply call application.UseDotnetResolver(serviceProvider)
passing an instance of dotnet's IServiceProvider
to it.