C# SDK samples should all use AddBotRuntime() in startup

[johnataylor]

The AddBotRuntime() extension function has been recently added to the SDK. This function registers with the Dependency Injection framework everything that is needed to run Adaptive Dialogs. This function builds the Composer runtime.

One of the important mechanisms at play here is that the various dependencies (the Adapter, Middleware, Storage, the Bot itself etc.) are added with the TryAddSingleton function, and this means they can be overridden.

While the default IBot that is registered actually runs Adaptive Dialogs it only takes a line of code in startup to override this with any other implementation. For example, an IBot implementation built in code derived from ActivityHandler. In other words there is nothing that limits this function to Adaptive Dialogs and Composer, it can be used to create the runtime for any IBot implementation.

Other than the obvious appeal of consistency and reuse, the advantage of using this approach is that the model shifts to one of overriding default working behavior with custom behavior. Previously the expectation was that the developer would have to know all the component parts and build up the runtime.

Although ultimately the developer who wishes to customize behavior will need to have an understanding of the various internal dependencies, what needs to be understood by the developer who just wants to get something working is significantly reduced.

This change also means there is an opportunity to consolidate aspects of the documentation as the way by which you customize and extend an Adaptive Dialog based Composer runtime is exactly the same way you customize and extend the runtime for a bot that was written all in code.

Specifically we should switch to using AddBotRuntime across all the SDK samples. For example:

services.AddSingleton<IBot, EchoBot>();
services.AddBotRuntime(Configuration);

and for a bot that uses Dialogs:

services.AddSingleton<MainDialog>();
services.AddSingleton<IBot, DialogBot<MainDialog>>();
services.AddBotRuntime(Configuration);

[johnataylor]

Related to #3284

[johnataylor]

@carlosscastro suggests we add appropriate remarks documentation comments to the product code to document the extensibility and customization points on the runtime.

Tracking issue in the SDK repo https://github.com/microsoft/botbuilder-dotnet/issues/5598

[johnataylor]

We should reassess the need for samples 21 (telemetry) and 81 (skills) as the AddBotRuntime function builds the necessary runtime. Illustrating that was the primary reasons for these samples being introduced.

Possibly we could keep 81, albeit in a simplified form, you at least need to add an extra controller on the parent for the skill callbacks.

And in place of the redundant sample 21 we could consider introducing a sample that illustrated how to override the default telemetry with a custom solution. This also highlights the advantage of standardizing on AddBotRuntime as such a sample would be equally applicable to both Composer and all code bots.

[msomanathan]

I tried modifying skills sample to use AddBotRuntime in the root bot and skill bot to verify the runtime's behavior. The sample works without any modifications needed in the runtime, but it did need the following changes to the sample (which may need to be looked at further as to whether the runtime can be modified to accommodate these):

• Samples for root bot and skill bot were modified to include the runtime skills settings to match the shape expected by the runtime "runtimeSettings:skills": { "AllowedCallers": [ "*" ] }
• The connection info of all skills supported by a given root bot is being managed by the bot code as SkillsConfiguration which takes its input from the appsettings "BotFrameworkSkills": [ { "Id": "YourSkillName", "AppId": "YourSkillAppId", "SkillEndpoint": "http://YourSkillHost/api/messages" } ]. If this config is moved into the runtime, the bot startup would not need to register SkillsConfiguration with DI.
• The AdapterWithErrorHandler in the root bot code currently needs to send EndOfConversation activity to the skill bot on any turn error. Similarly, the adapter in skill bot needs to send EoC to root bot on turn error. So, the CoreBotAdapter that is used by the runtime may need knowledge about parent/child bots to whom the EoC needs to be sent.
• I am currently investigating if it would be possible for custom adapters that handle proactive messages (like, Human Handoff scenario for example) could instead use CoreBotAdapter to achieve the same functionality. This would eliminate the need to register a custom adapter in startup.