DI in the Interaction- & Command Service
For both the Interaction- and Command Service modules, DI is quite straight-forward to use.
You can inject any service into modules without the modules having to be registered to the provider.
Discord.Net resolves your dependencies internally.
[!WARNING]
The way DI is used in the Interaction- & Command Service are nearly identical, except for one detail:
Resolving Module Dependencies
Registering the Service
Thanks to earlier described behavior of allowing already registered members as parameters of the available ctors,
The socket client & configuration will automatically be acknowledged and the XService(client, config) overload will be used.
[!code-csharpService Registration]
Usage in modules
In the constructor of your module, any parameters will be filled in by
the @System.IServiceProvider that you've passed.
Any publicly settable properties will also be filled in the same
manner.
[!code-csharpModule Injection]
If you accept Command/InteractionService or IServiceProvider as a parameter in your constructor or as an injectable property,
these entries will be filled by the Command/InteractionService that the module is loaded from and the IServiceProvider that is passed into it respectively.
[!NOTE]
Annotating a property with a [DontInjectAttribute] attribute will
prevent the property from being injected.
Services
Because modules are transient of nature and will reinstantiate on every request,
it is suggested to create a singleton service behind it to hold values across multiple command executions.
[!code-csharpServices]
