同时引用Microsoft.Data.SqlClient与System.Data.SqlClient会引发哪些问题？

核心逻辑：为何混用要严格避免 #

这两个数据提供程序属于不同的.NET程序集，虽然核心类型名（如SqlConnection、SqlParameter）完全一致，但归属不同命名空间，CLR会将它们视为完全独立的类型，这种“同名不同类”的特性会引发一系列难以排查的兼容性问题。

场景一：直接引用两个包的具体问题 #

• 类型不兼容导致运行时异常：除了你提到的SqlConnection共享、SqlParameter跨传递报错外，SqlCommand、SqlTransaction等核心对象也存在同样问题——哪怕属性结构完全一致，强行转换或跨传递都会抛出InvalidCastException，且编译阶段无法提前发现。
• 连接池碎片化：两个提供程序维护各自独立的连接池，区分依据是「连接字符串+程序集标识」。若代码中混用两类客户端创建相同连接字符串的连接，会导致连接池无法复用连接，整体连接数快速膨胀，直接触发数据库连接上限。
• 事务上下文断裂：用其中一个客户端开启的事务，无法被另一个客户端的连接加入，会导致事务边界混乱，出现数据不一致、事务回滚失败等问题。
• 特性与行为差异：Microsoft.Data.SqlClient支持Azure AD认证、SQL Server UTF-8等新特性，而System.Data.SqlClient保留了部分旧版兼容逻辑，混用会引发预期外行为——比如超时参数解析逻辑不同、参数类型映射差异等。
• 依赖注入冲突：若DI容器注册了其中一类客户端实例，代码中误注入另一类，会直接导致服务解析失败或运行时逻辑错误。

场景二：间接引用另一个包的问题 #

即便项目只显式引用一个包，第三方DLL间接引入另一个的情况同样会触发问题：

• 隐式类型转换报错：第三方DLL返回的SqlConnection等对象，与项目中使用的并非同一类型，编译时因类型名一致不会报错，但运行时会抛出类型转换异常，排查难度极高。
• 连接池资源浪费：第三方DLL用另一类客户端创建的连接，会进入独立的连接池，导致整体连接数超出数据库限制，表现为连接超时、“泄漏”的表象。
• 版本冲突异常：若第三方引用的SqlClient版本与项目中不一致，会触发程序集绑定失败、MissingMethodException等问题——比如Microsoft.Data.SqlClient新增的方法在旧版本中不存在，第三方调用时直接报错。

与Hangfire连接泄漏的关联 #

Hangfire依赖SqlClient操作数据库，若项目中存在两类客户端混用，可能通过以下路径引发连接泄漏：

• Hangfire初始化使用一类客户端，业务代码使用另一类，导致连接池无法复用，连接数持续增长至数据库上限，表现为“泄漏”。
• 第三方依赖间接引入另一类客户端，Hangfire处理任务时无意中创建了不受其管理的连接，这些连接未被正确释放，长期积累导致泄漏。
• 类型不兼容引发未捕获异常，导致连接未被正确关闭或归还至连接池。

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