As per the Microsoft documentation on DTEXEC for executing SSIS packages:
When you use the version of the dtexec utility that comes with SQL
Server 2012 Integration Services (SSIS) to run a SQL Server 2005
Integration Services (SSIS) or a SQL Server 2008 Integration Services
(SSIS) package, Integration Services temporarily upgrades the package
to SQL Server 2012 Integration Services (SSIS).
Is there a feature to disable this aspect of DTEXEC utility when running SSIS packages?
My reason for this question is that I have a script task to rename some files in an SSIS package. This works just fine on my local machine and a coworkers local machine, but after deploying this SSIS package to our windows 2012 server with SQL Server 2012 installed I get an error message. I'm really confused, because I wrote this package in SQL Server 2012 Data Tools so this task shouldn't need to be upgraded/migrated at all, which is what the error is complaining about…
Warning: 2016-04-06 11:29:58.14
Code: 0x00000000
Source: DataMergeScriptTask
Description: Found SQL Server Integration Services 2012 Script Task "my_Script_task" that requires migration!End Warning
Error: 2016-04-06 11:30:03.02
Code: 0x00000001
Source: DataMergeScriptTask
Description: Exception has been thrown by the target of an invocation.End Error
Best Answer
Unfortunately we haven't found a solution for the Script Task not converting into 2012, as these packages are all written in Data Tools 2012 and opening/resaving the task doesn't seem to actually upgrade the script task in a way that solves it on the server.
My solution has been to take the C# script and turn it into a standalone .exe which has some command line arguments to pass our different parameters with defaults in place to match our current environment. Then I set this up to be executed by a Batch script called by a windows task scheduler job.
I'm hoping to find a real fix for this so that script tasks in larger packages will still be peachy, but that may take more time or a reinstall of data tools... Having multiple versions of SQL Server data tools/BIDS on my workstation could be a cause of this grief. More testing to come!