Having problems with IoC

[MiniaczQ]

I've ran into some unexpected problems with Microsoft IoC extension.
Here's the code:
https://github.com/MiniaczQ/commanddotnet-ioc/blob/main/Program.cs
(in one file purely for convenience)

I thought resolver would provide the service to the command, but that wasn't the case.
The error message

CommandDotNet.InvalidConfigurationException: type : `commanddotnet_ioc.Program+IMyService` is not supported.
If it is an argument model, inherit from IArgumentModel.
If it is a service and not an argument, register using AppRunner.Configure(b => b.UseParameterResolver(ctx => ...));
Otherwise, to support this type, implement a TypeConverter or IArgumentTypeDescriptor or add a constructor with a single string parameter.

suggests one of 3 things:

• The class may have been a collection of arguments (IArgumentModel)
• The class may have been constructed from a single argument (opt. 3) if only I provided the necessary tools
• The class could have been injected if I registered it with a parameter resolver
  It's also the only option with any idea of IoC

I looked for similar usages in examples and tests, but nothing really struck be as similar.
In fact I'm not sure what the tests are actually testing. There is some interception going on, but none of that was mentioned in IoC on docs.

My questions would be:

• Does the thing I'm trying to achieve make sense? I know it's only gonna run a single time, but DI is helpful in unit testing.
• Was that the expected behavior?
• Did I miss some configuration?

Relevant discussions:
#437
appears to have an almost identical test case, the end result was not working, so the issue wasn't resolved.

[drewburlingame]

Ok, the code example was helpful and I understand why it's failing for you. We have not added support to resolve method parameters from the container. If we did, we might follow the pattern of ASP.NET and require the parameter to be attributed with [FromServices] (You could propose this as a feature and submit a PR if you'd like)

CommandDotNet expects the command class to be created by the DI container and in that case, you'd inject the dependencies via constructor or property injection, depending on what you've enabled in the container. This way, the DI container owns the instance of the command class. In your example, Program is a command class since it defines commands.

public class Program
{
    static int Main(string[] args)
    {
        var services = new ServiceCollection();
        services.AddSingleton<IMyService>(new MyService());
        services.AddSingleton<Program>();
        return new AppRunner<Program>()
            .UseMicrosoftDependencyInjection(services.BuildServiceProvider())
            .Run(args);
    }

	private IMyService _myService;

	public Program(IMyService myService) => _myService = myService;

    public void Test(
        Arguments args,
        IConsole consoleService)
    {
        consoleService.WriteLine(_myService.Foo(args.Arg1, args.Arg2));
    }
}

sidenote: in #437, he seems to have gotten the DI to work but there was a null ref in the Print method of his code. He no longer had errors from his container while resolving the property.

[drewburlingame]

I think the term service is also confusing in that error. Services will mean something different depending on the context your thinking from.

For a CommandDotNet middleware developer, this would be a service specific to the middleware, such as IConsole in your example above.

For an application developer working with a DI container, it makes sense to think of this as a DI service. And an application developer could also register parameter resolvers for services from the container, so the error message does apply in some ways.

Perhaps in the documentation we should explicitly state that we do not resolve parameters from the container and that if this is required, a ParameterResolver will need to be registered. Would this have helped you?