ASP.NET Core 6下同代码OperationContextScope异常排查

你对NuGet版本差异的怀疑方向完全正确，两份相同代码表现不一致的核心原因和依赖版本、运行时异步调度逻辑直接相关，不存在新手认知偏差。

核心触发逻辑 #

OperationContextScope 本身是为同步调用场景设计的组件，强依赖创建时所在的线程同步上下文：

• 当你在using代码块内使用await时，默认配置下await执行完成后会从线程池取空闲线程执行后续逻辑，不一定回到创建OperationContextScope的原始线程
• 当using块结束触发Dispose()时，如果当前线程持有的OperationContext和scope创建时绑定的上下文不匹配，就会抛出乱序释放的错误
• 你断点无法捕获异常的原因很简单：这个错误不是在await client.GetListAsync()这行抛出的，而是在整个using块执行到末尾、scope执行Dispose校验上下文一致性时才触发，异常挂在异步方法的状态机延续任务上，普通行断点自然无法命中。

同代码不同表现的根因 #

两个项目必然存在以下差异之一，才会导致一个报错一个正常：

• 引用的System.ServiceModel.*系列WCF客户端NuGet包版本不一致：.NET 6平台下的WCF客户端移植包在4.10版本前对异步上下文的兼容存在已知缺陷，部分版本下如果GetListAsync刚好同步完成（比如命中本地缓存、服务端响应速度快到被运行时优化为同步返回），就不会触发线程切换，自然不会报错；版本差异会改变异步任务的调度逻辑，直接决定是否触发跨线程释放问题。
• 项目编译配置存在差异：如果其中一个项目配置了WPF/WinForm SDK（即csproj中存在<UseWPF>true或<UseWindowsForms>true>配置），会默认注入UI线程同步上下文，await之后会强制回到原始线程执行后续逻辑，不会触发上下文不匹配问题；而纯ASP.NET Core MVC项目默认没有自定义同步上下文，await后直接走线程池调度，很容易触发错误。
• 存在程序集引用混用：如果其中一个项目错误引用了.NET Framework原生GAC中的System.ServiceModel程序集，而非.NET Core官方移植的NuGet包，异步逻辑处理规则完全不同，也会出现表现差异。

修复方案 #

不要依赖默认using块包裹带await的OperationContextScope逻辑，改成手动控制scope生命周期，从根源规避跨线程释放问题，修改后代码如下：

var scope = new OperationContextScope(client.InnerChannel);
try
{                       
    SoapAuthenticationHeader.Create(client.ClientCredentials.UserName.UserName, 
    client.ClientCredentials.UserName.Password);

    zWsGetList = CreateZWSGetListObject(param);

    var GetListResponse1 = await client.GetListAsync(zWGetList).ConfigureAwait(false);

    // 剩余业务逻辑
}
finally
{
    scope.Dispose();
}

同时执行以下排查操作彻底消除环境差异：

• 对齐两个项目所有System.ServiceModel.*开头的NuGet包版本，优先升级到最新稳定版，删除所有直接引用GAC中.NET Framework原生WCF程序集的配置
• 对比两个项目的csproj配置，移除不必要的WPF/WinForm SDK引用，确保运行时同步上下文行为一致

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