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

Abhishek Modi (amodi) 20 Reputation points

We observed that DTExec.exe.config (SQL Server 2025 SSIS runtime) contains an assemblyBinding bindingRedirect entry for Microsoft.Data.SqlClient with oldVersion="0.0.0.0-5.0.0.0" redirecting to newVersion="5.0.0.0".

We integrate DTExec-based SSIS execution from our product/runtime and also manage dependencies via GAC/NuGet.

We need to understand why this range is explicitly specified, and whether Microsoft expects this to remain stable or change in future updates.

A typical entry look like:

<dependentAssembly>
  <assemblyIdentity name="Microsoft.Data.SqlClient" publicKeyToken="23ec7fc2d6eaa4a5" culture="neutral" />
  <bindingRedirect oldVersion="0.0.0.0-5.0.0.0" newVersion="5.0.0.0" />
</dependentAssembly>

I would like to understand below queries, Can you please review them and provide your feedback:

  1. What is the design reason DTExec (SQL Server 2025 / SSIS) ships with a bindingRedirect for Microsoft.Data.SqlClient with range 0.0.0.0–5.0.0.0?
  2. Range for Microsoft.Data.SqlClient ="0.0.0.0-5.0.0.0" means: any request for Microsoft.Data.SqlClient with assembly version within this range should be required or needed always?
  3. Does SQL Server 2025 ship DTExec/SSIS components compiled with an assembly reference that expects Microsoft.Data.SqlClient up to assembly version 5.0.0.0? Is 5.0.0.0 the assembly version used by the SqlClient assembly that SSIS ships/targets for SQL 2025?
  4. Does this range “change later” in future?

Thanks,

Abhishek

0 comments No comments
Sign in to comment

Answer recommended by moderator

Akhil Gajavelly 1,830 Reputation points • Microsoft External Staff • Moderator

Hi @Abhishek Modi (amodi) ,

One additional point to make this explicit for SQL Server 2025 specifically:

For a given SQL Server major version like 2025, the oldVersion="0.0.0.0-5.0.0.0" range is stable for that release line it reflects the highest Microsoft.Data.SqlClient version that SSIS was built and tested against at ship time.

  • The lower bound 0.0.0.0 is a convention and never changes
  • The upper bound 5.0.0.0 is tied to the SqlClient version adopted by SSIS for that SQL Server release

Even across cumulative updates for SQL Server 2025, this ceiling is unlikely to move, because adopting a new major SqlClient version (e.g. 6.x) is a meaningful dependency change that kind of shift is generally reserved for a new SQL Server major release rather than a CU.

Practically, this means you can treat 5.0.0.0 as the stable ceiling for your SQL Server 2025 deployment planning, but still avoid hardcoding it reading newVersion directly from DTExec.exe.config at deploy time protects you when the next major SQL Server version eventually does move the ceiling.

Thanks,
Akhil.

0 comments No comments
Sign in to comment

3 additional answers

  1. Bruce (SqlWork.com) 84,086 Reputation points

    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.

    0 comments No comments
    Sign in to comment
  2. Akhil Gajavelly 1,830 Reputation points • Microsoft External Staff • Moderator

    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
    1. 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.

    1. 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.

    1. 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. Abhishek Modi (amodi) 20 Reputation points

      Hi @Akhil Gajavelly ,

      Thank you for the response.

      Does the 0.0.0.0 value always represent the lower bound (floor), for Microsoft.Data.SqlClient, specifically for SQL Server 2025?

      In other words, later in future will the lower version range ever move beyond 5.0.0.0, or does it remain capped at that version for SQL Server 2025 in DTExec.exe.config?

      Thanks,

      Abhishek

    2. Akhil Gajavelly 1,830 Reputation points • Microsoft External Staff • Moderator

      Hi @Abhishek Modi (amodi) ,

      Just checking in to see if the above explanation around SQL Server 2025 SqlClient version binding (0.0.0.0 - 5.0.0.0 range) helped clarify your scenario.

      As mentioned, for SQL Server 2025, this range is expected to remain stable across CUs, and reading the newVersion dynamically from DTExec.exe.config is the recommended approach to stay future-proof.

      If you’ve had a chance to validate this on your end, please let us know how it went. In case you’re still seeing any unexpected behavior, feel free to share additional details we’ll be happy to take a closer look.

      Thanks,
      Akhil.

    3. Akhil Gajavelly 1,830 Reputation points • Microsoft External Staff • Moderator

      Hi @Abhishek Modi (amodi) ,

      Just following up to see whether the explanation regarding SQL Server 2025 SqlClient version binding (0.0.0.0 –5.0.0.0 range) helped clarify the behavior you were observing.

      As noted earlier, this binding range is expected to remain consistent across SQL Server 2025 cumulative updates, and reading the newVersion value dynamically from DTExec.exe.config remains the recommended future-proof approach.

      If you’ve been able to test this in your environment, please let us know the outcome. Otherwise, if you’re still encountering any unexpected behavior, feel free to share the latest details and we can continue investigating further.

      Thanks.,
      Akhil.

    Sign in to comment

  3. AI answer

    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:

    AI-generated content may be incorrect. Read our transparency notes for more information.
Sign in to answer

Your answer