1

Hi I'm looking for some guidance.

I've developed an SSIS project with a couple of script tasks and script components using visual studio 2015 for targeted version 2016.

I have two environment server A and server B both have SSIS 2016 SP1 installed on it.

I have done a project deployed of the packages to Sever A and tested the packages everything executed perfectly. However when I deployed the packages in SSIS_DB from Server A to Server B I get these errors in my execution report.

The component metadata for "script component, clsid { }" could not be upgraded to the newer version of the component. The PerformUpgrade method failed

2

There was an exception while loading Script Task from XML: System.Exception: The Script Task "" uses version 15.0 script that is not supported in this release of Integration Services. To run the package, use the Script Task to create a new VSTA script. In most cases, scripts are converted automatically to use a supported version, when you open a SQL Server Integration Services package in %SQL_PRODUCT_SHORT_NAME% Integration Services. at Microsoft.SqlServer.Dts.Tasks.ScriptTask.ScriptTask.LoadFromXML(XmlElement elemProj, IDTSInfoEvents events)

The interesting part is if I deploy my packages directly from visual studio to Server B the packages executes correctly with no issue. So there seems to be inconsistencies between server A and Server B.

A small background to this is that when both servers were built Server A had Microsoft SQL Server 2016 (SP1-GDR) and Server Microsoft SQL Server 2016 (RTM) but they both now have Microsoft SQL Server 2016 (SP1-GDR) after Server B was updated. I'm not sure how the upgrade was done by my suspicion is that the SSIS on server are different but I can't seem to prove it. when I check the version they both seem to return same or similar meta data

Nathan TSQL_Jr
  • 117
  • 1
  • 8
  • https://stackoverflow.com/questions/50215249/ispac-file-deployment-errors-out-when-build-deploy-from-visual-studio-works-fine#comment87447259_50215249 This question has been asked a number of times here, but I don't see a solution other than to deploy from VS. – Tab Alleman May 08 '18 at 13:11
  • As discussed in https://stackoverflow.com/a/50229977, either deploy from VS or deploy with **IsDeploymentWizard** from MS SQL Program Bin folder. – Ferdipux May 18 '18 at 10:26

3 Answers3

2

The right answer is here: https://andyleonard.blog/2017/09/ssis-version-15-0-script-error/

In my case the problem was the setting at the project level “TargetServerLevel” set to “SQL Server 2017”. The correct value must be “SQL Server 2016”. Once the value is changed and the project redeployed errors desappear. I believe one of developers in my team used VS 2017 when added the project. All other tasks and components, excep script, were fine even with incorrect server version and the problem appeared only when I had to use script tasks and components.enter image description here To fix the problem open project parameters => Configuration Properties => TargetServerVersion Select “SQL Server 2016”, then deploy to the server.

Alexey Sukhanov
  • 309
  • 4
  • 3
  • I had this same problem and chaging `TargetServerVersion` to _SQL Server 2016_ resolved the issue: the SQL Server Agent job (which invokes the dtsx package) ran successfully. – fdkgfosfskjdlsjdlkfsf Oct 05 '21 at 13:44
1

This was caused by SSMS. I don’t know what’s going on under the hood but During the deployment I was using SSMS 2017 which seems to be upgrading script components in my packages. I changed to use SSMS 2016 and this issue disappeared

Nathan TSQL_Jr
  • 117
  • 1
  • 8
0

Just summarizing some things because there are some reasons for facing this problem:

  1. Your are deploying a package with Target Version Definition for another SQL Server

enter image description here

  1. You are deploying a package which contains a script task with not same SSMS version as SQL Server Version

enter image description here

If your package doesn't contain a script task for example, then any version of SSMS can deploy the package to any version of SQL Server via SSISDB catalog. Not sure why is this happening. Seems that you can deploy and execute packages while making sure that the package target version is supported from SQL Version, but also if you have a ScriptTask inside you need to be super careful and make sure also that the integration services version of SSMS is the same with SQL Server version.

I will open a question to Microsoft just to be sure why the script task has this treatment. Maybe is because the script task is Framework dependent.

Stavros Koureas
  • 1,126
  • 12
  • 34