Open HiltonGiesenow opened 9 months ago
@HiltonGiesenow Hmmm. Interesting request. My assumption was that this class, and the other Configuration* classes, were in Integration due to IConfiguration. I would not have expected them to work in Connector. The original goal was to avoid integration specific code in the "lower" layers since most of the stack is not integration specific. We'd need to do some research because my first question is why does it even build in Connector.
Ah ok, I see what you mean. I guess maybe it depends on whether you classify IConfiguration
as an 'Integration'? At the moment, now that I look more, it means there are classes that are practically 100% duplicated, for instance ConfigurationChannelProvider
and ConfigurationCredentialProvider
, between Microsoft.Bot.Builder.Integration.AspNet.WebApi
and Microsoft.Bot.Builder.Integration.AspNet.Core
, which is probably not ideal?
If it really makes sense to split IConfiguration-dependent elements out, perhaps there should be a Microsoft.Bot.Builder.Integration
?
Is your feature request related to a problem? Please describe. I'm working on other cloud hosting options for a bot, and would like to use
ConfigurationBotFrameworkAuthentication
, but I need to bring the entireMicrosoft.Bot.Builder.Integration.AspNet.Core
assembly along for the ride at the moment, just for this single class, which itself it not actually bound to anythingAspNety
at all.Describe the solution you'd like Based on the above, I'm requesting this be unbundled and moved into
Microsoft.Bot.Connector
, where it's base classBotFrameworkAuthentication
lives. I'm happy to submit a PR for this, perhaps with some guidance if needed.Describe alternatives you've considered Right now, I'm creating a copy of
ConfigurationBotFrameworkAuthentication
in my new project.Additional context N/A