CommandsService.LoadAssembly should not attempt to install modules without a valid constructor.

In the current behavior, if a module has an invalid constructor (e.g. requiring a DiscordSocketClient), the LoadAssembly method will throw an InvalidOperationException and crash.

In some cases, users may intend to have only certain modules use custom constructors, while leaving the rest of their modules default.

Projected Change: If the assembly crawler fails to find a valid constructor for a class, skip over that module, rather than hard-failing.

I can create a fix if this issue is deemed unintended behavior.

[ghost]

Along with what @khionu and @420foxbot suggested, I think it would also be useful to pass the CommandsService instance in the module constructor. I have to use a static variable to pass it as I need the CommandsService instance to implement a help command, and it was also useful to implement commands to help debug type readers.

The constructors I’d want would probably be something like this:

Module(IDiscordClient client)
Module(CommandsService commands)
Module(IDiscordClient client, CommandsService commands)

As for user feedback on modules failing to load, I’d say issuing a Warning and continuing the load would be the best approach. If an attribute were introduced, it would probably be better to mark classes we don’t want to autoload, rather than classes which should autoload, as it makes it clear we have to explicitly load the module rather than have it load automatically.

[Auralytical]

As per Discord convo:

• Add an opt-out property in the Module attribute to avoid autoloading.
• Don’t hardcode support for constructor properties (except CommandsService I guess), route everything through an optional simple DI (little more than a user friendly Dictionary<Type, object>)
• Maybe expose an interface so people can use their own DI if they want