Hello @csharpfritz .
Right now all IBasicCommand and IExtendedCommand are got via scanning Assembly and added to IServiceCollection with singleton lifetime.
|
public static void RegisterCommands(IServiceCollection services) |
|
{ |
|
// Register basic commands |
|
foreach (var type in typeof(FritzBot).Assembly.GetTypes() |
|
.Where(t => typeof(IBasicCommand) |
|
.IsAssignableFrom(t) && !t.IsAbstract && t.IsClass)) |
|
{ |
|
services.AddSingleton(typeof(IBasicCommand), type); |
|
} |
|
|
|
// Register extended commands |
|
foreach (var type in typeof(FritzBot).Assembly.GetTypes() |
|
.Where(t => typeof(IExtendedCommand) |
|
.IsAssignableFrom(t) && !t.IsAbstract && t.IsClass)) |
|
{ |
|
services.AddSingleton(typeof(IExtendedCommand), type); |
|
} |
|
} |
I'm suggesting changing this behavior to adding commands explicitly in startup for two reasons :
- In order to inject a scoped service like
DbContext, the command needs to be scoped or transient.
- We could prevent adding some command in startup based on configuration and prevent running a command (even
CanExecute).
Hello @csharpfritz .
Right now all
IBasicCommandandIExtendedCommandare got via scanning Assembly and added toIServiceCollectionwith singleton lifetime.Fritz.StreamTools/Fritz.Chatbot/FritzBot.cs
Lines 63 to 80 in 78587eb
I'm suggesting changing this behavior to adding commands explicitly in startup for two reasons :
DbContext, the command needs to be scoped or transient.CanExecute).