Releases: mgrosperrin/commandlineparser
v0.13.0
New feature
What else
- The build and deployment system (for the package & the documentation site) is now powered by GitHub Actions
Full Changelog: 0.12.0...0.13.0
0.12.0
What's new?
Add missing extension's methods to IHost
& IHostBuilder
the parser engine from the command provider
The new methods will match the existing one on the IParser
interface:
ParseCommandLineAndExecuteAsync
will callParse
,ParseCommandLineAndExecuteAsync<TCommand>
will callParse<TCommand>
,ParseCommandLineWithDefaultCommandAndExecuteAsync<TCommand>
will callParseWithDefaultCommand<TCommand>
.
[Breaking changes] Update dependencies
The dependencies of the libraries (Microsoft.Extensions.DependencyModel
, Microsoft.Extensions.DependencyInjection
, Microsoft.Extensions.Logging
, System.ComponentModel.Annotations
, Microsoft.Extensions.Hosting
) have been updated to 5.0.x.
[Breaking changes] Polishing the public API
A lot of small changes as been made to the public API to simplify the usage of the library.
v0.11.0
What's new?
[Breaking changes] Decouples the parser engine from the command provider
The way command are defined are now decoupled from the parser engine. This allow introducing another way to define commands. This release introduce MGR.CommandLineParser.Command.Lambda
to define command defined on the fly which the execution is based on lambda.
The primary interface to implement is MGR.CommandLineParser.Extensibility.Command.ICommandTypeProvider
.
Due to the decoupling, the IParser.Parse
methods now returns a ParsingResult
. Its main properties/methods are:
CommandObject
: anICommandObject
that represents the command,IsValid
: a boolean that indicates if the parsing operation was successfull, and the command has no validation errors,ValidationResults
: the list ofValidationResult
ExecuteAsync
: the method that will execute the command is everything is correct.
[Breaking changes] The command execution are now asynchronous
The int ICommand.Execute()
method is now Task<int> ICommand.ExecuteAsync()
.
Similary, the package MGR.CommandLineParser.Command.Lambda
only define asynchronous commands.
[Breaking changes] Use Microsoft.Extensions.DependencyInjection
The library is now using the DI abstraction provided by Microsoft instead of the custom one. This will simplify defining commands that inject services.
The parser now requires a IServiceProvider
when calling one of the parse methods. There is extensions methods that uses the default built-in service provider.
To use your own service provider with the library, you have to register the parser's services by calling AddCommandLineParser
on your IServiceCollection
. The method returns a CommandLineParserBuilder
that allow you adding custom services (currently there is built-in methods to add custom ICommandTypeProvider
: AddClassBasedCommands (the previous legacy behavior), AddCommands<TCommand>
(adds all class-based commands on the assembly containing the TCommand
class), and AddCommand
from MGR.CommandLineParser.Command.Lambda
package (add a lambda-based command).
Define your commands without creating a new class
The new MGR.CommandLineParser.Command.Lambda
package allow you to define commands on the fly by using command.
You have to register the command to your own service provider to define lambda-based commands (see above).
Introduce integration with the new generic host
The new MGR.CommandLineParser.Hosting
introduce integration with the new generic host APIs.
The integration has two part:
- Registering the parser's services: call
ConfigureParser
on an instance ofIHostBuilder
. You can register the command providers with this method. - Parse and execute the command: call
ParseCommandLineAndExecuteAsync
on either theIHostBuilder
or theIHost
. The result of this method is the parsing result, or the result of the command execution.
What else?
Use of Azure DevOps to build and release
The library now use Azure DevOps to build and release the library.
v0.10.0
What's new?
[Breaking changes] Convertion to .NET Standard 2.0 (#58)
The library is now a .NET Standard 2.0 library. as part of the conversion, the MEF attribute has been removed (the usage of MEF to retrieve the command has been removed in a previous version.
[Breaking changes] Short name for option can only be used with simple dash (#67)
Boolean options can be merged with their short name (#68)
This allow you to define multiple boolean options and specify their value with only one flag in the arguments.
[Breaking changes] Use double dash to use option with full name (#69)
An option can only be specified via its long name with double dashes. /
do no longer work.
v0.9.0
What's new?
Allow options to be specified in kebab-case (#49)
The options can now be specified in the command line in kebab-case.
Add the possibility to define a default command (#48)
You can now decided to parse the command line by using a default command if none are specified in the arguments.
var parserBuild = new ParserBuilder();
var parser = parserBuild.BuildParser();
var commandResult = parser.ParseWithDefaultCommand<MyDefaultCommand>(arguments);
What else?
This next version will support .NET Standard 2.0. The support for .NET framework that not implement the standard could be dropped (depending on the overhead it implies).
The build now compute prerelease version by starting at 1 for each new version (instead of continualy incrementing the number) (#57).
v0.8.0
What's new?
Clean the public API (#44 & #37)
All point of extensibility has been moved to the namespace MGR.CommandLineParser.Extensibility
.
With this move, the only types in the namespace MGR.CommandLineParser
and MGR.CommandLineParser.Command
are the ones for the consumer.
All attributes to define the metadatas of commands have been merged to a single attribute (MGR.CommandLineParser.Command.CommandAttribute
).
Add the ability to hide a command from command listing (#38)
It is now possible to hide a command from command listing in help while been runnable (for example for pre-release command).
What's fixed?
- A
DirectoryNotFoundException
is thrown if there is a space in the folder containing the application (#46)
v0.7.0
What's new?
Support for response file (#21)
You can now provide a pth to a response file instead of passing arguments. The file path must be provided as the very first argument (before the name of the command), prefixed by a @
. The file must have the extension .rsp
and should contains each argument on its own line.
Double dash to specify raw argument (#23)
If you want to put items in the Arguments
list of a command that would be treated as parameters, you can now use the special separator --
. Every items after this separator will be added the the Arguments
list.
Imporve usage of custom DI systems (#27)
All default types are now public in order to allow them to be used with a custom DI systems instead of reimplementing them.
What's fixed?
- The
DependencyResolverCommandActivator
throws an exception when trying to resolver a command (#28)
What else?
The build is now done with Cake build. The build versions, creates a package and publish it to MyGet (for alpha release) or NuGet (for beta and stable release) (#13 #25)
v0.6.0
What's new ?
Add new converter for DirectoryInfo
and FileInfo
(#10)
You can now have a property of type System.IO.DirectoryInfo
or System.IO.FileInfo
that well be automatically be converted from the command line.
Change the interface ISampleCommand
to an attribute (#9)
The interface MGR.CommandLineParser.Command.ISampleCommand
(used to provide sample the Help
command has been converted to the attribute MGR.CommandLineParser.Command.SampleCommandAttribute
in order to avoid creation of the command to show the samples.
Rename ServiceResolverCommandActivator
to DependencyResolverCommandActivator
(#2)
The type MGR.CommandLineParser.ServiceResolverCommandActivator
(a non-default implementation of MGR.CommandLineParser.ICommandActivator
) has been renamed to MGR.CommandLineParser.DependencyResolverCommandActivator
to match the name of the DependencyResolver
.
Change registrying of dependencies (#3)
Register a dependency through the MGR.CommandLineParser.DefaultDependencyResolver.RegisterDependency
method now takes a Func<Func<IDependencyResolverScope, T>>
argument. The outer Func
will be called everytime a new IDependencyResolverScope
is created. The inner Func
will be called everytime a service has been to be resolved for a particular scope.
Register a list of dependencies through the MGR.CommandLineParser.DefaultDependencyResolver.RegisterDependencies
method now takes a Func<Func<IDependencyResolverScope, IEnumerable<T>>>
argument. The Func
s wil be called in the same manner that for a single dependency.