Closed Simonl9l closed 2 months ago
So my work around, is to have the top level command, inherit a base impl have all the arguments and option and just delegate that to a base class implementation.
It would be grand in the future for the code/analyzer generator to detect option comments on a base class for a function of the same name (override etc), and pick of the <param name"">.. specification from there so its DRY'er.
Suggestion - you might want to consider enabling Discussions on this repo - to handle these cases?
Just reading docs, experimenting a little, and finding my way around - on first look this CLI library is very intriguing!
I'm looking at migration from
cocona
, given the AoT support. I'm current leveraging is support for inheritance (usingclass
thanrecord
) withICommandParameterSet
one can also define argument orders between the parent and base options and the cli will order them according. I'm trying to work out how this figures into my migration plan.I have a scenario where I have a number of cli's (or possibly commands in the same cli) each have a common behavior that ordinarily each could have a common base class. That base class need access to some base arguments and options.
However with the comment
///
based annotation to define these arguments options I'm not sure how to proceed.I can potential see this issue might cover the common arguments/options - https://github.com/Cysharp/ConsoleAppFramework/issues/140
I also see this related PR - https://github.com/Cysharp/ConsoleAppFramework/pull/100
Do you have any recommendations of what I can do now?
Thanks again for all the effort put into this Library!