In a previous blog post, I showed you how you can set a target server version for an SSIS project in SSDT on VS2015 in order to deploy packages to multiple versions of SSIS catalogs. This is pretty cool, but if you deploy a project with a version that is newer than your SSIS catalog, you will get an error stating "The version number in the package is not valid. The version number cannot be greater than the current version number." This all has to do with the PackageFormatVersion of the dtsx file. If you open one of your packages in notepad, you can see the version. A package that is SQL 2014 or SQL 2016 will be version 8 as shown below.
For this use case, the SSIS project needed to deployed to a SQL 2012 instance. In SSDT the project was configured for SQL 2012 and all seemed well.
If you viewed the dtsx file in notepad, the PackageFormatVersion reflected the change that was made to the project.
To deploy the project, the ISPAC file to deploy to a SQL 2012 SSIS Catalog. Note that the client machine had SQL 2014 client tools running on it. It will be pretty common for DBAs to have the version of SQL client tools that reflect the highest version in their environment. While we would all love to have all our SQL instances on the latest and greatest version of SQL Server, that is simply not realistic in most companies. Here you can see the package was deployed to a SQL 2012 instance
After the project was deployed, an attempt was made to run the package and it failed. The error message states the version number is not valid and shows the PackageFormatVersion is version 8, even though it was version 6 when the project was built.
You can also see the PackageFormatVersion in the internal.packages table in SSISDB on the SQL 2012 version… it is set to version 8.
Getting around this problem is pretty easy. Copy the ISPAC file to the server hosting SQL2012. You can then run the ISPAC file from an RDP session on the SQL 2012 server in order to use SQL 2012 client tools. You can see that now the package is using the PackageFormatVersion of 6. Note that since SSIS versions packages, that is why you see 2 entries for the package.
The package ran successfully!
I hope if you stumble across this error, you will find this blog post and get an easy resolution to the problem.