9

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 '17 at 2:38
4

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.

  • I would love to know why the workaround works. – Zach Smith Jul 27 '17 at 12:36
4

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" 
/DestinationServer:"server01" 
/DestinationPath:"/SSISDB/Projects/Project"

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 '18 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 at 20:25
0

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.

-1

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 '18 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 '18 at 8:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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