Is there support for Dependency Injection

When constructing the instance of from the array of types provided to the ParseArguments it would be nice if the instance supplied had it’s dependencies resolved via constructor arguments. Perhaps this is already in place and I’m just not seeing how it’s configured?

[JaronrH]

I’m a huge fan of Micorosft’s DI so I ended up writing my own DI extension for CommandLineParser. You’re welcome to try it out for yourself here: https://github.com/JaronrH/CommandLineParser.DependencyInjection

1. Add your Options as classes (Verbs or single options class) and have them implement ICommandLineOptions (interface does nothing on it’s own). These should not require DI injection as they are just used to identify Options using DI!
2. Create a service that implements IExecuteCommandLineOptions<TCommandLineOptions, TResult>. TCommandLineOptions should be an options class from step 1 and TResult is what the parser will ultimately return as a result.
3. [Optional] Implement a service that implements IExecuteParsingFailure<out TResult>. This will allow you to handle errors from the parser.
4. Setup DI and use the AddCommandLineParser() extension to IServiceCollection to add the CommandLineParser DI extensions (pass in the assemblies that contain the above implementations). This uses Scrutor (https://github.com/khellang/Scrutor) to scan the assemblies and add them as needed.
5. After building your IServiceProvider, you can request the parser or have it injected in a service constructor. i.e. request service ICommandLineParser<int>
6. Use parser.ParseArguments(args) to parse and execute. Behind the scenes, this creates the parser using the class type(s) registered as ICommandLineOptions in DI from step 1. If the parser is successful, the DI attempts to resolve the corresponding IExecuteCommandLineOptions<TCommandLineOptions, TResult> service from DI (step 2). Otherwise, the optional IExecuteParsingFailure<out TResult> service from DI is used from step 3 (if defined, otherwise, we return default(TResult)).

If you want to manually control what gets pulled into DI, just use AddCommandLineParser() without passing in any assemblies and then register the implementations yourself.

Note: If you want the help information dispatched to the console, you will need to specify that in the configuration. For example: parser.ParseArguments(args, o => { o.HelpWriter = System.Console.Error; });

Hope that helps!

[TheTrigger]

i haven’t looked at the library code yet, but i think you can keep single responsibility and without adding aspnetcore dependency. How? Allowing us to intervene between data type detection and creation of the instance

• Parse command to only detect type
• allow us to run ActivatorUtilities.CreateInstance and give back the instance to commandlineparser
• commandlineparser populates properties

thoughts?