I added a script task to an SSIS project in VS2015. When I deployed to SQL Server 2016 I got an error message that the version 15.0 script is not supported.

Where does this version 15 come from? Reading other, similar questions on Stack Overflow I see that you can set the target version of the project to SQL Server 2012 - which I did (the eventual deployment target is SQL Server 2012).

I also tried deleting and recreating the script task. And in the information of the script it says it's using V10 of C#.

How can I resolve this?

Script Task:Error: There was an exception while loading Script Task from XML: System.Exception: The Script Task ""ST_a1ad9dc5972c42b68c12a13155f10b6d"" 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)"

I have also opened the project in SSDT 2012 and rebuilt with a different name. Same error. It seems that there must be a reference that wasn't deleted or something.

None of the solutions on this question (https://stackoverflow.com/questions/34893267/ssis-script-task-vs15-not-work-when-deploy-on-sql-server-2014) worked.

Looking at the XML in the package where the script is, I can easily find that task, and there is no reference to version 15 anywhere.

=========== EDIT

After copying the project to the machine that hosts the database, opening VS2015 and deploying from there, the package executes.

And then when going back to my machine and building there, it doesn't.

Is this a bug? Or am I doing something stupid by expecting the build to produce the same deployment wizard as using the wizard from VS...

I have SQL Server 2016 (13.0.4411.0), ssisdb has the schema version (13.0.1601.5).

I am using an integration services package created in visual studio 2015. The script component has the path: C:\Program Files (x86)\Microsoft SQL Server\130\DTS\Binn\VSTA14_IS_ST_CS_Template.vstax It won't let me execute the package through the integration services catalog (due to the message experienced by Zach). However it appears that it will let me execute it through the file system (using SQL Agent). Unsure if this is working, will update this once the package has completed.

  • I've noticed the same when specifying package versions. I built my project and copied the wizard across forgetting to change the SQL Server target version. I got an error that the Target version was too high. When I rebuilt with the corrected target version I got the same error, despite that the XML showed the corrected target version
    – Zach Smith
    Jul 6, 2017 at 2:38

7 Answers 7


I believe I have the same issue, and here is the work around that got over my issue.

Details first:

  • I have sql server 2016 (13.0.4411.0)
  • SSISDB has the schema version (13.0.1601.5)
  • I am using an integration services package created in visual studio
  • The script component (Which states it is 2015 C#) has the path: C:\Program Files (x86)\Microsoft SQL Server\130\DTS\Binn\VSTA14_IS_ST_CS_Template.vstax

If I deploy to the catalog through SSMS, it won't let me execute the package through the integration services catalog (due to the message experienced by Zach - version 15.0 not supported).

The workaround:

If I deploy the package through Visual Studio to the 'Integration Services Catalog' on the required instance, this message goes away and the project runs successfully. This is not ideal as we should be able to deploy through SSMS, but meant that the project can progress.

  • 1
    I would love to know why the workaround works.
    – Zach Smith
    Jul 27, 2017 at 12:36

My DBA finally figured this out for me and the issue was that I was deploying through SSMS 2017 without realizing it. The error message led me astray but your workaround helped lead to the reasoning behind the failure. I guess you can try SSMS 2016 and see if that works. The other way that my DBA suggested is to use the command line. Something like this, with 130 highlighted since that is the version you need for 2016:

"C:\Program Files (x86)\Microsoft SQL Server\130\DTS\Binn\ISDeploymentWizard.exe" 
/Silent /ModelType:Project 
/SourcePath:"E:\ssis\Project Path\bin\Development\Project.ispac" 

I hope that helps clear this up. I worked on it for a long, long time before finding your workaround and then finally finding this solution. So thanks!

  • what do you mean by "deploying through SSMS 2017 without realizing it"? I use VS 2017 to deploy.. and there is a setting that allows you to define the version of SQL Server you are targeting. But I found that didn't work
    – Zach Smith
    Jan 23, 2018 at 16:51
  • This worked for me. Deploying directly from SSDT worked but we could not do that remotely, deploying via SSMS 2017 would not work, and then using the command line option via the 2016 ISDeploymentWizard.exe did work. Thanks!
    – Clinemi
    Mar 4, 2019 at 20:25

Along similar lines to others, I originally deployed to SQL2014 using the SQL2017 deployment wizard. This produced the runtime error. When I used the SQL2014 deployment wizard everything worked fine.


The actual reason of this issue is the source of the deployment. While you are trying to deploy a package containing a script task to SQL server with higher SSMS version then the xml definition is changing. You should use same version of SSMS as SQL Server.

This is also relative with the issue in connecting to integration services with SSMS. For example you can have multiple SSIS versions side by side which they don’t have named instances and connecting to each other by simply using different SSMS versions.


I see that problem mentioned by https://dba.stackexchange.com/users/48093/sqlworldwide is somewhat same for me. I found the solution by creating a build of the project in VS2015. After which I do get ".ispac" located inside bin\Development folder. This file I copied on the target server and run it simply to import all th3 packages without any issue.

  • As it’s currently written, your answer is unclear. Please edit to add additional details that will help others understand how this addresses the question asked. You can find more information on how to write good answers in the help center.
    – Community Bot
    Mar 12, 2023 at 5:25

I thought I would add to this, as I was getting the same error. I am running VS 2017 and deploying to a 2016 SQL Server. I read quite a few articles, then realized just how easy it was for me to fix this. VS 2017 has great backwards compatibility.

This article on changing the version of an SSIS package to match the version of your target server helped me resolve the error in my case.

  • Note that the OP said he tried changing the target server in his case, but it didn't work. Of course (as noted in the article), if he had used a feature not available in the target version, things wouldn't work because of that.
    – RDFozz
    Feb 22, 2018 at 18:07
  • Yes - just changing the target version didn't work. However, changing the target version and then deploying locally through VS 2017 did work - so I suspect a bug in VS 2017 (at least when I asked the question) with regards to how the deployment wizard is created. (I'm assuming since this approach worked that I didn't use incompatible features)
    – Zach Smith
    Feb 23, 2018 at 8:05

I just opened the package via view code. Searched the xml for VSTA and where it said "15" I changed to "14". Ran no more script error.

  • 1
    While this may have worked for your package, changing the version number like that might make the package unusable if it has version 15 features in use.
    – Hannah Vernon
    Oct 28, 2020 at 19:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.