- Notifications
You must be signed in to change notification settings - Fork 286
Open
Description
I'm using the Value attribute, and specifying some parameters like this ...
[Verb("fetch",HelpText="Download a zip of scraped documents from each agent.")]publicclassFetchScrapedOptions{ #region Properties [Value(0,HelpText="Local path to destination directory for downloaded zips.")]publicstringLocalDestinationPath{get;set;}[Value(1,HelpText="Remote path to the input directory of csvs.")]publicstringRemoteInputPath{get;set;}[Value(2,HelpText="Remote path to the output directory of jsons.")]publicstringRemoteOutputPath{get;set;} #endregion }This code above seems to work as intended, but if you reposition the LocalDestinationPath property down below the others it no longer works as intended. The provided CLI args no longer match up to the specified Value position, yet the help text still specifies the position defined in Value. So something there isn't matching up.
[Verb("fetch",HelpText="Download a zip of scraped documents from each agent.")]publicclassFetchScrapedOptions{ #region Properties [Value(1,HelpText="Remote path to the input directory of csvs.")]publicstringRemoteInputPath{get;set;}[Value(2,HelpText="Remote path to the output directory of jsons.")]publicstringRemoteOutputPath{get;set;}[Value(0,HelpText="Local path to destination directory for downloaded zips.")]publicstringLocalDestinationPath{get;set;} #endregion }The main issue being that Value doesn't seem to actually cause the parsing of CLI args to match the specified property based on the position provided. It looks like it maps to props based on their order in the class which seems odd.
Metadata
Metadata
Assignees
Labels
No labels