Composer项目中MS Botframework自定义ActivityHandler实现主动消息问题

问题背景说明 #

你之前的方案失效是因为Composer生成的项目本身自带默认的IBot实现（ComposerBot），你直接将IBot的实现替换为自定义的ActivityHandler子类，会完全覆盖Composer原生的对话调度逻辑，自然无法触发你在Composer中定义的对话流。 #

问题1：兼容Composer的ConversationReference获取方案 #

有两种无需修改核心Bot注册逻辑、完全兼容Composer原生能力的实现方式：

• 自定义动作方案：开发C#自定义动作，在动作执行逻辑中直接从TurnContext中调用turnContext.Activity.GetConversationReference()获取会话引用，可搭配IStorage接口实现持久化存储。将自定义动作拖入Composer对话流的对应节点即可按需收集，不会影响原有对话逻辑。
• 中间件方案：在Startup.ConfigureServices中注册自定义中间件，在中间件的OnTurnAsync方法中拦截所有传入活动，全局提取所有会话的ConversationReference，无需修改Composer侧的对话设计，对原有逻辑无侵入。

问题2：使用ActivityHandler时兼容Composer对话的配置方法 #

如果必须通过继承ActivityHandler实现需求，不要直接替换IBot的基础实现：

1. 自定义的ProactiveBot类改为继承Composer默认的ComposerBot类（而非直接继承ActivityHandler，ComposerBot本身就是ActivityHandler的子类）
2. 重写你需要的ActivityHandler相关方法（比如OnMessageActivityAsync、OnConversationUpdateActivityAsync等）时，必须在自定义逻辑末尾调用base.对应方法(turnContext, cancellationToken)，将处理权交回Composer原生的对话调度逻辑
3. 注册服务时，将原来Composer默认的AddBot<ComposerBot>的泛型参数替换为你的ProactiveBot即可，不要自行重新注册IBot的实现

补充方案说明 #

你提到的2.1及以上版本schema的技能实现主动消息的方案同样可行，将主动消息逻辑封装为独立技能，Composer开发的主机器人直接调用该技能即可，属于低耦合的实现方式，适合多机器人场景复用主动消息能力。

内容的提问来源于stack exchange，提问作者Marc Rey