Share via

Confirmation on Maintenance Plan DLL Usage for SQL Server 2025

Abhishek Modi (amodi) 20 Reputation points
2026-05-25T14:13:00.8+00:00

Hello Team,

Earlier, till SQL Server 2022 (version up to 16) we were compiling our Maintenance Plan source code project by referencing the required DLLs from the GAC.

However, for SQL Server 2025 (version 17), based on our analysis of the DTExec.exe.config file and runtime behavior, the SSIS runtime appears to resolve the client side assemblies from the SQL Server installation directory: "...\Microsoft SQL Server\170\DTS\Binn"

Specifically, we are referencing the following assemblies from this path for compile-time use:

  1. Microsoft.SqlServer.ConnectionInfo.dll
  2. Microsoft.SqlServer.Management.Sdk.Sfc.dll
  3. Microsoft.SqlServer.Smo.dll
  4. Microsoft.SqlServer.SqlEnum.dll
  5. Microsoft.Data.SqlClient.dll

We are currently compiling the Maintenance Plan source code project using these DLLs from the above path. 

Accordingly, we are evaluating whether referencing these assemblies from SQL Server installation path and we would like to confirm if this approach is supported and feasible for SQL Server 2025 going forward.

 

Thank you for your support.

 

Thanks,

Abhishek

SQL Server Integration Services
0 comments

1 answer

Sort by: Most helpful
Most helpful Newest Oldest

  1. AI answer

    2026-05-25T14:13:29.8366667+00:00

    Referencing those assemblies directly from the SQL Server 2025 installation path (for example, …\Microsoft SQL Server\170\DTS\Binn and …\170\SDK\Assemblies) for compile-time is not the recommended or supported approach going forward.

    For SQL Server 2025 (v17), the supported guidance is:

    1. Prefer the Microsoft.SqlServer.SqlManagementObjects NuGet package
      • This package provides the SMO assemblies (including Microsoft.SqlServer.Smo.dll, Microsoft.SqlServer.SqlEnum.dll, and related dependencies).
      • It is versioned and maintained specifically for SQL Server compatibility and is strong-named and Authenticode signed.
      • This avoids tight coupling to a particular local SQL Server installation path and reduces versioning/build issues.
    2. Avoid mixing GAC/installation-path assemblies with NuGet SMO
      • Mixing assemblies from C:\Windows\Microsoft.NET\assembly\GAC_MSIL or …\Microsoft SQL Server\170\DTS\Binn with NuGet-based SMO references leads to version conflicts and build errors (as seen with CS1705 and missing/incorrect versions of Smo and SqlEnum).
      • If NuGet-based SMO is used, keep all SMO-related references from that package only.
    3. If GAC/installation-path deployment is mandatory
      • Wait for the official SQL Server 2025 Feature Pack or SharedManagementObjects.msi, which will install the appropriate v17.100+ assemblies into the correct locations.
      • Those redistributables are the supported way to obtain and redistribute SMO binaries outside of NuGet.
    4. Use the SDK assemblies for SSIS/maintenance-plan integration
      • For SSIS and maintenance-plan–related code, reference SDK assemblies from C:\Program Files\Microsoft SQL Server\170\SDK\Assemblies\ (not SSMS UI or DTS\Binn design-time binaries) when SDK-based development is required.
      • Ensure the “Client Tools SDK” feature is installed via SQL Server 2025 setup if that folder is missing.

    Summary:

    • Using …\170\DTS\Binn assemblies directly as compile-time references is not the supported long-term pattern.
    • Use Microsoft.SqlServer.SqlManagementObjects (NuGet) for SMO, and the official SQL Server SDK/redistributables for SSIS/maintenance-plan code.
    • Avoid mixing installation-path DLLs and NuGet/GAC SMO assemblies to prevent version and build issues.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.