| Property | Value |
|----------|-------|
| Error Number | 171 |
| Message (SQL Server 2019+) | “The package failed validation. The package contains a component that is not supported on the target platform.” |
| Typical Source | Data Flow → OLE DB Source / Destination, ADO.NET, Script Component, or any custom component that was built for a different SSIS version/bitness. |
| Why It Happens | The runtime engine (DTExec / SSIS Catalog) cannot locate, load, or run the component because of one (or more) of the following mismatches:
1. Version mismatch – component compiled for SSIS 2008/2012 but running on SSIS 2019+.
2. Bitness mismatch – 32‑bit component on a 64‑bit run‑time (or vice‑versa).
3. Missing assembly – DLL not present in the GAC or in the C:\Program Files\Microsoft SQL Server\150\DTS\Binn folder.
4. Platform target – the package was saved as “SQL Server 2008” (or an older version) but is being executed on a newer server that enforces “TargetServerVersion”. |
| Impact | Package validation fails before any data moves. The package never starts, and the SSIS Catalog logs the error with severity 16. |
Assume the offending component is MyCompany.CustomTransform.dll.
# 4️⃣ Path where SSIS expects third‑party components
$ssisBin = "C:\Program Files\Microsoft SQL Server\150\DTS\Binn"
# 5️⃣ Copy the DLL (choose 64‑bit version)
Copy-Item "C:\Deploy\MyCompany.CustomTransform.x64.dll" -Destination $ssisBin -Force
# 6️⃣ Register it in the GAC (optional but recommended)
& "$env:windir\Microsoft.NET\Framework64\v4.0.30319\gacutil.exe" /i "$ssisBin\MyCompany.CustomTransform.x64.dll"
Write-Host "Component copied and GAC‑registered."
If you have a vendor MSI – run it on the server. It will place the DLL in the right folder and register it automatically. SSIS-171
| ✅ Preventive Action | How to Implement |
|----------------------|-------------------|
| Lock the Target Server Version | Add <TargetServerVersion>SQLServer2022</TargetServerVersion> to the .dtproj and check‑in the project file in source control. |
| Enforce 64‑bit Development | In the Solution → Properties → Debug, set Run64BitRuntime = true and make it a team‑wide Visual Studio setting (via a .vsconfig file). |
| Package‑Level Component Whitelisting | Create a PowerShell validation script that scans the .dtsx for any component whose classID is not in an approved list. Fail the CI build if it finds a rogue component. |
| Automated Deployment of Third‑Party DLLs | Use a SQL Server Agent job or Octopus Deploy step that copies the required DLLs to DTS\Binn and runs gacutil /i. Keep the DLLs version‑controlled. |
| Continuous Integration (CI) Validation | Add a MSBuild /t:Validate step in your build pipeline (SSDT 2022+ supports /t:Validate). Capture the output; any 171 will break the build. |
DTExec /ISSERVER "\SSISDB\MyFolder\MyProject\MyPackage.dtsx" /REPORTING V /DIAG
The log will contain a line like:
[OLE DB Destination [1]] Error: 171: The package failed validation. Component XYZ is not supported on this platform.
Note the full component name (XYZ) and the assembly path (if printed).
# 7️⃣ Use dtexec to validate only (no execution)
$dtexec = "C:\Program Files\Microsoft SQL Server\150\DTS\Binn\DTExec.exe"
& $dtexec /ISSERVER "\SSISDB\MyFolder\MyProject\MyPackage.dtsx" /VALIDATE
You should see:
Package validation succeeded.
If you still get 171, repeat Section 3 diagnostics to catch any secondary component.
Open the package in a text editor (or use SSDT → View Code) and search for: | Property | Value | |----------|-------| | Error
<component name="MyComponent" classID="GUID" version="2.0" ... />