Strategies for Dependency Injection in CommandSettings for Enhanced Argument Handling

[andreasciamanna]

Context:

I'm working with commands that have optional arguments, specifically "source" and "target" branches of the local repository in the directory where the command is executed. When these arguments are omitted, their values are inferred using injected service classes. This inference includes identifying the current local branch as a "source" or fetching the default branch from an API based on the repository host (e.g., GitHub, GitLab, etc.). As this logic is crucial, an exception is thrown if a branch cannot be detected. These optional parameters are used by more than one command.

The Problem:

The logic to infer these parameters is repeated across each command that requires the optional(ish) parameters, leading to code duplication. While I have reduced this duplication by creating helper methods, it has not been completely eliminated.

Proposed Solution:

I propose moving this inference logic to the class extending CommandSettings.

Ideally, this logic would run before the interceptor class is triggered, allowing for programmatic changes in the settings' values or throwing an exception if the program cannot infer values for these arguments.

It would streamline the process by placing the logic in a more suitable location within the flow, particularly within the settings validation method (since there isn't a sanitation method, which would be probably more suited to this scope).

Challenges Faced:

It appears that DI can't be used on classes extending CommandSettings.

When attempting to use DI in the settings class, I encounter a CommandRuntimeException due to the absence of a parameterless constructor in the settings class. Here's the specific exception encountered:

Spectre.Console.Cli.CommandRuntimeException: Could not resolve type '<NAMESPACE>.SettingsWithBranches'.
 ---> System.MissingMethodException: Cannot dynamically create an instance of type '<NAMESPACE>.SettingsWithBranches'. Reason: No parameterless constructor defined.

---

I am exploring whether this is a feature currently unsupported by spectre.console or if there's an existing way to achieve this that I might be overlooking.

Having recently returned to C#/.NET development after a decade with other languages, I am eager to learn about any new practices or patterns that I might have missed.

Any guidance, suggestions, or insights would be greatly appreciated in helping to enhance argument handling in this context.

Thanks,
Andrea

[WurliMonkhaven]

Are you using the standard DI pattern, or .NET Generic Host?

[WurliMonkhaven]

Worth noting the context of that comment; @gitfool was referring to another comment someone else made where they were doing something funky. The approach by @thoemmi is pretty effective though.

I don't know if it will solve your problem but it may be worth exploring. At the very least it will give you more fine-grained control over what you're doing.

[andreasciamanna]

Ah, I see. I got confused.

I'll try that then, but do you think that would allow me to inject the dependency to the settings class?

[WurliMonkhaven]

On reflection, I'm not sure if this will get you closer to your goal, sorry.

Have you considered creating a base class for your commands, and injecting your required code in the base constructor? I have no idea if this would work but it's a thought.

[andreasciamanna]

Have you considered creating a base class for your commands and injecting your required code in the base constructor? I have no idea if this would work, but it's a thought.

It can help, but not in the way I want to.

I want the settings validation to infer the option's value and fail if it can't.
This would also work with the summary of the argument values I would output on every command, so the user can see what are the inferred values.

With the base class approach (for the command, not the settings), I might be able to do so, but I will still need to duplicate a bunch of code (e.g. always calling the base constructor, as well as the base's "Execute" method, most likely: I didn't fully picture yet how I would implement this approach).

[WurliMonkhaven]

It's not uncommon practice for classes inheriting a base class to require a base() constructor call. I guess you could have your base class call some base method for calculating these strings. I agree it's not as pretty as automagic tho.