Kiwify.Kiwi.CLI.DependencyInjection 1.0.0

Kiwify.Kiwi.CLI.DependencyInjection

ServiceProviderCommandResolver - wires a standard IServiceProvider into Kiwi CLI so that command objects are constructed via dependency injection.

Target: netstandard2.1 Dependencies: Kiwify.Kiwi.CLI, Microsoft.Extensions.DependencyInjection.Abstractions

What it provides

The core Kiwify.Kiwi.CLI library defines only ICommandResolver - a single-method interface with no external dependencies. This project provides the concrete implementation that bridges ICommandResolver to Microsoft's standard DI container.

Usage

1. Register services and command types

using Microsoft.Extensions.DependencyInjection;
using Kiwify.Kiwi.CLI.DependencyInjection;

var services = new ServiceCollection();

// Application services
services.AddSingleton<IEmailService, SmtpEmailService>();
services.AddSingleton<IUserRepository, SqlUserRepository>();

// Command types - registered so the resolver can construct them
services.AddTransient<SendOptions>();
services.AddTransient<UserInfoOptions>();

var provider = services.BuildServiceProvider();

2. Attach the resolver

using Kiwify.Kiwi.CLI;

var app = new CommandLineApplication("mytool", "1.0.0", "My CLI tool.");

app.AddCommand(sendCommand);
app.LoadCommandFrom<UserInfoOptions>();

// Attach before Execute - propagates to all registered commands
app.AttachCommandResolver(new ServiceProviderCommandResolver(provider));

app.Execute(args);

3. Accept injected services in the command object

public class SendOptions
{
    private readonly IEmailService? _email;

    public SendOptions() { }  // fallback when no resolver is attached

    public SendOptions(IEmailService email)
    {
        _email = email;
    }

    public string To      { get; set; } = "";
    public string Subject { get; set; } = "";

    // Fluent handler - opts is DI-constructed, so _email is populated
    public void Execute(IOutput output)
    {
        _email?.Send(To, Subject);
        output.WriteResult("Sent.");
    }
}

For declarative commands, the [CliHandler] method is public static. The injected value arrives via the first parameter:

[CliCommand("user-info")]
public class UserInfoOptions
{
    private readonly IUserRepository? _users;

    public UserInfoOptions() { }
    public UserInfoOptions(IUserRepository users) { _users = users; }

    [CliOption("--id", "-i", IsRequired = true)]
    public int UserId { get; set; }

    [CliHandler]
    public static void Handle(UserInfoOptions opts, IOutput output)
    {
        var user = opts._users?.GetById(opts.UserId);
        // ...
    }
}

Container-agnostic design

The framework never calls IServiceCollection, BuildServiceProvider, or any container-specific API. It calls only resolver.Resolve(Type commandType), which returns object?.

To use a different container (Autofac, Lamar, Simple Injector, etc.), implement ICommandResolver directly:

public class AutofacCommandResolver : ICommandResolver
{
    private readonly IContainer _container;
    public AutofacCommandResolver(IContainer container) => _container = container;
    public object? Resolve(Type commandType) => _container.ResolveOptional(commandType);
}

Fallback behaviour

If the resolver returns null (the type is not registered), the framework falls back to Activator.CreateInstance<TCommand>(). If no parameterless constructor exists, an InvalidOperationException is thrown with a clear message indicating the type must be registered with the resolver.

See also

• ICommandResolver - the interface this project implements
• DependencyInjectionSample - end-to-end example
• Advanced.md - full DI documentation