Comment changer une version de tâche de script dans SSIS?

J'ai ajouté une tâche de script à un projet SSIS dans VS2015. Lorsque j'ai déployé sur SQL Server 2016, j'ai reçu un message d'erreur indiquant que le version 15.0script n'est pas pris en charge.

D'où cela vient-il version 15 come from? En lisant d'autres questions similaires sur Stack Overflow, je constate que vous pouvez définir la version cible du projet sur SQL Server 2012 - ce que j'ai fait (la cible de déploiement éventuelle est SQL Server 2012).

J'ai également essayé de supprimer et de recréer la tâche de script. Et dans les informations du script, il indique qu'il utilise la V10 de C #.

Comment puis-je résoudre ça?

Tâche de script: erreur: une exception s'est produite lors du chargement de la tâche de script à partir de XML: System.Exception: la tâche de script "" ST_a1ad9dc5972c42b68c12a13155f10b6d "" utilise le script de la version 15.0 qui n'est pas pris en charge dans cette version d'Integration Services. Pour exécuter le package, utilisez la tâche de script pour créer un nouveau script VSTA. Dans la plupart des cas, les scripts sont convertis automatiquement pour utiliser une version prise en charge, lorsque vous ouvrez un package SQL Server Integration Services dans% SQL_PRODUCT_SHORT_NAME% Integration Services. sur Microsoft.SqlServer.Dts.Tasks.ScriptTask.ScriptTask.LoadFromXML (XmlElement elemProj, événements IDTSInfoEvents) "

J'ai également ouvert le projet en SSDT 2012 et reconstruit avec un nom différent. Même erreur. Il semble qu'il doit y avoir une référence qui n'a pas été supprimée ou quelque chose.

Aucune des solutions sur cette question ( /programming/34893267/ssis-script-task-vs15-not-work-when-deploy-on-sql-server-2014 ) n'a pas fonctionné.

En regardant le XML dans le package où se trouve le script, je peux facilement trouver cette tâche, et il n'y a aucune référence à la version 15 nulle part.

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

Après avoir copié le projet sur la machine qui héberge la base de données, ouvert VS2015 et déployé à partir de là, le package s'exécute.

Et puis quand je retourne à ma machine et que j'y construis, ce n'est pas le cas.

Est-ce un bug? Ou est-ce que je fais quelque chose de stupide en m'attendant à ce que la génération produise le même assistant de déploiement que l'utilisation de l'assistant de VS ...

J'ai SQL Server 2016 (13.0.4411.0), ssisdba la version de schéma (13.0.1601.5).

J'utilise un package de services d'intégration créé dans Visual Studio 2015. Le composant de script a le chemin d'accès: C:\Program Files (x86)\Microsoft SQL Server\130\DTS\Binn\VSTA14_IS_ST_CS_Template.vstaxil ne me permet pas d'exécuter le package via le catalogue des services d'intégration (en raison du message rencontré par Zach). Cependant, il semble qu'il me permettra de l'exécuter via le système de fichiers (à l'aide de l'Agent SQL). Je ne sais pas si cela fonctionne, le mettra à jour une fois le package terminé.

Je crois que j'ai le même problème, et voici le travail qui a surmonté mon problème.

Détails d'abord:

• J'ai le serveur SQL 2016 (13.0.4411.0)
• SSISDB a la version de schéma (13.0.1601.5)
• J'utilise un package de services d'intégration créé dans Visual Studio
• Le composant de script (qui indique qu'il s'agit de 2015 C #) a le chemin: C: \ Program Files (x86) \ Microsoft SQL Server \ 130 \ DTS \ Binn \ VSTA14_IS_ST_CS_Template.vstax

Si je déploie dans le catalogue via SSMS, cela ne me permettra pas d'exécuter le package via le catalogue des services d'intégration (en raison du message rencontré par Zach - la version 15.0 n'est pas prise en charge).

La solution:

Si je déploie le package via Visual Studio dans le «catalogue Integration Services» sur l'instance requise, ce message disparaît et le projet s'exécute correctement. Ce n'est pas idéal car nous devrions pouvoir déployer via SSMS, mais cela signifie que le projet peut progresser.

Mon DBA a finalement compris cela pour moi et le problème était que je déployais via SSMS 2017 sans m'en rendre compte. Le message d'erreur m'a induit en erreur, mais votre solution de contournement a contribué au raisonnement derrière l'échec. Je suppose que vous pouvez essayer SSMS 2016 et voir si cela fonctionne. L'autre façon que mon DBA a suggéré est d'utiliser la ligne de commande. Quelque chose comme ça, avec 130 en surbrillance puisque c'est la version dont vous avez besoin pour 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"

J'espère que cela aide à clarifier cela. J'ai travaillé dessus pendant très longtemps avant de trouver votre solution de contournement et enfin de trouver cette solution. Donc merci!

Dans le même esprit que d'autres, j'ai initialement déployé sur SQL2014 à l'aide de l'assistant de déploiement SQL2017. Cela a produit l'erreur d'exécution. Lorsque j'ai utilisé l'assistant de déploiement SQL2014, tout a bien fonctionné.

J'ai pensé que j'allais ajouter à cela, car je recevais la même erreur. J'exécute VS 2017 et déploie sur un serveur SQL 2016. J'ai lu pas mal d'articles, puis j'ai réalisé à quel point il était facile pour moi de résoudre ce problème. VS 2017 a une grande compatibilité descendante.

Cet article sur la modification de la version d'un package SSIS pour correspondre à la version de votre serveur cible m'a aidé à résoudre l'erreur dans mon cas.