SQL Server 2025 - DTExec.exe.config file included assembly dependancies range for Microsoft.Data.SqlClient.dll

Binding redirects are required when a project has multiple dll that reference a common dll, but the dll’s are built to different versions of that dll. Dtexec.exe obviously has a dll that references Microsoft.Data.SqlClient 5.0.0, and another dll (which probably was not updated for this release) which references an earlier version of Microsoft.Data.SqlClient. While there probably is not a dll referencing version 0, the convention in config is 0 to highest version referenced.

This binding redirect could be updated on a later release that had a module that referenced a later release of Microsoft.Data.SqlClient.

Hi @Abhishek Modi (amodi) ,

The existing answer covers by AI the basics well, but there are three things it missed that directly affect your integration.

1. In-process hosting AppDomain isolation

If your product invokes DTExec out-of-process (shell spawn), you're fine. But if you're hosting in-process or sharing an AppDomain, DTExec.exe.config binding redirects only cover DTExec's AppDomain not yours. You'll need a matching redirect in your own config, otherwise expect:

• FileLoadException
• MissingMethodException
• Type identity mismatches where typeof(SqlConnection) != typeof(SqlConnection) across the boundary these are especially hard to diagnose

2. NuGet version vs CLR identity version critical for GAC deployment

The existing answer never made this actionable. 5.0.0.0 is the CLR identity version, not the NuGet package version. Concretely:

NuGet 5.1.5  →  CLR identity 5.0.0.0  satisfies redirect

NuGet 5.2.2  →  CLR identity 5.0.0.0  satisfies redirect

NuGet 6.0.0  →  CLR identity 6.0.0.0  breaks falls outside range

Deploying a 6.x package to your GAC thinking it's "newer = better" will silently break the redirect.

3. Don't hardcode 5.0.0.0 in your deployment logic

When SSIS adopts SqlClient 6.x, this redirect ceiling moves up. Read newVersion directly from DTExec.exe.config at deploy time so your GAC management stays automatically aligned across SQL Server updates.

4. Will the range change in future updates?

Almost certainly yes, when Microsoft moves SSIS to SqlClient 6.x. Expect it to become.

<bindingRedirect oldVersion="0.0.0.0-6.0.0.0" newVersion="6.0.0.0" />

The 0.0.0.0 floor always stays only the ceiling and target version move up with each major SqlClient adoption.

Practical tip: Don't hardcode 5.0.0.0 in your deployment or GAC management logic. Instead, read the newVersion value directly from DTExec.exe.config at deploy time that way your integration automatically stays aligned whenever SQL Server ships an update.

Thanks,
Akhil.

1. The bindingRedirect for Microsoft.Data.SqlClient in DTExec.exe.config follows the same pattern used for other SSIS/BizTalk/SQL client assemblies: it allows the SSIS runtime to load a specific, tested version of a dependency even if packages or custom components were built against earlier versions. This is the same design pattern described for SSIS custom components where configuration files add binding redirection rules so that components compiled against older assembly versions (10.x, 11.x, 12.x, etc.) can run on a newer runtime by redirecting to a single, supported version. In other words, the redirect is there so that:
   • SSIS/DTExec can standardize on one Microsoft.Data.SqlClient version at runtime.
   • Packages or components that reference earlier Microsoft.Data.SqlClient versions in that range can still execute without needing to be recompiled, as long as they are compatible with the redirected version.
2. A range oldVersion="0.0.0.0-5.0.0.0" means: any assembly binding request for Microsoft.Data.SqlClient whose version falls within that numeric range is redirected to newVersion="5.0.0.0". It does not mean that such a reference is “always required”; it only defines what happens if such a reference is made at runtime. If no code requests Microsoft.Data.SqlClient, the redirect is not used. If code requests any version up to and including 5.0.0.0, the .NET loader will bind it to 5.0.0.0.
3. The pattern in the provided context shows that SQL Server/SSIS tools and related products ship with explicit binding redirects to a specific assembly version they target. For example, BizTalk’s bm.exe.config redirects a range of SQL Server Integration Services assemblies (e.g., Microsoft.SqlServer.DTSRuntimeWrap, Microsoft.SqlServer.ManagedDTS) from 0.0.0.0-15.0.0.0 to 16.0.0.0, indicating that the product is built and tested against those specific versions and wants all lower versions to unify on that version at runtime. By analogy, a redirect to Microsoft.Data.SqlClient newVersion="5.0.0.0" indicates that the SSIS/DTExec runtime is standardized and tested on Microsoft.Data.SqlClient 5.0.0.0, and any compatible lower versions in the specified range are unified to that version. The context also shows that Microsoft.Data.SqlClient 5.x is supported across SQL Server 2012–2025, Azure SQL Database, and related services, which aligns with using 5.x as a common runtime target.
4. Whether the range changes later is a product/servicing decision and is not specified in the provided context. The context only shows the general pattern:
   • Products add binding redirects to move older assembly versions to a specific newer version (for example, SSIS components redirected to 15.0.0.0 or 16.0.0.0).
   • New driver versions (for example, Microsoft.Data.SqlClient 6.x, 7.x) are introduced over time, with evolving features and dependency changes.
   Based on this pattern, future SQL Server/SSIS updates could introduce new redirects (for example, to a newer Microsoft.Data.SqlClient version) or adjust ranges, but no specific commitment or schedule is stated in the context.

References:

• KB5048971 - Improvement: Support for Windows Server 2022, Windows 11, and SQL Server 2022 in BizTalk Server 2020
• Upgrade Integration Services Packages
• SqlClient driver support lifecycle
• Introduction to Microsoft.Data.SqlClient namespace