DLL异步方法执行长耗时操作时如何向ASP.NET调用方上报进度？

1 原生.NET层进度上报抽象（基础必做） #

不管后续选什么通信方案，DLL层优先做逻辑解耦：

• DLL的异步方法签名添加IProgress<CustomProgressPayload>类型参数，CustomProgressPayload为自定义结构，可包含进度百分比、当前操作描述、错误码等自定义字段
• DLL内部每完成一个操作节点，调用IProgress<CustomProgressPayload>.Report()方法抛出当前进度，不要在DLL内耦合任何ASP.NET上下文、通信相关逻辑
• 上层ASP.NET层直接用.NET自带的Progress<T>类实现IProgress<T>接口，自动捕获同步上下文，无需自己处理跨线程回调的线程安全问题

2 客户端-服务端通信方案 #

2.1 短轮询 #

适用场景：实时性要求低、并发量小、需要兼容极低版本浏览器

• ASP.NET层收到操作请求后启动DLL异步任务，生成唯一任务ID存入缓存（内存缓存/分布式缓存均可），同步更新缓存中该任务的最新进度
• 服务端将任务ID返回给客户端
• 客户端每隔1~5秒携带任务ID发起查询请求，服务端返回对应任务的当前进度，直到任务完成/失败
• 优点：实现最简单，兼容性无死角
• 缺点：进度更新有延迟，高频轮询会增加服务端压力

2.2 Server-Sent Events（SSE） #

适用场景：仅需服务端单向推送进度、实时性要求中等

• ASP.NET层收到请求后设置响应头Content-Type: text/event-stream，保持HTTP长连接不关闭
• 将Progress<T>的回调逻辑绑定为向SSE流写入进度数据，DLL每上报一次进度就主动推给客户端
• 任务结束后主动关闭SSE连接
• 优点：比轮询性能高、实时性更强，实现比WebSocket简单，现代浏览器原生支持
• 缺点：仅支持单向通信，不兼容IE10及以下版本

2.3 WebSocket（推荐用SignalR封装） #

适用场景：实时性要求高、后续可能扩展双向交互功能

• 直接用ASP.NET官方的SignalR类库，自动封装了WebSocket、长轮询等多种传输方式，无需自行处理连接管理、断线重连、传输协商等底层逻辑
• 客户端连接SignalR Hub后触发长耗时任务调用，将当前连接ID和任务ID做绑定
• Progress<T>回调触发时，服务端通过SignalR Hub上下文，向对应连接ID的客户端推送进度消息
• 优点：实时性最高、性能最好，官方类库和.NET生态完全兼容
• 缺点：需要维护Hub逻辑，服务端资源占用高于短轮询

• Microsoft.AspNetCore.SignalR：ASP.NET官方实时通信类库，无第三方依赖，支持自动选择最优传输方式，断线重连、分组推送等功能均已内置，选WebSocket/SSE方案时优先使用
• Hangfire：如果长耗时任务需要支持后台持久化执行（客户端断开连接也不中断任务）、重试、失败告警，可以用Hangfire托管DLL异步任务，自带可视化面板查看所有任务状态，可自行扩展进度存储逻辑配合上述通信方案使用
• System.Threading.Progress：.NET 原生自带的IProgress<T>实现，直接调用即可，无需额外引入依赖

• 任务ID建议用GUID生成，避免重复冲突，进度缓存需设置合理过期时间，避免内存泄漏
• 执行时间超过10分钟的任务建议将进度、状态持久化到数据库，服务端重启后可恢复任务进度，无需用户重新触发操作

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