SSIS Error - The version number in the package is not valid

Question

The logs corresponding to the failed job are as follows:

04/11/2014 06:40:00,LPR_New,Error,0,USPHND0088,LPR_New,(Job outcome),,The job failed. The Job was invoked by Schedule 14 (LPR_New_Job). The last step to run was step 1 (Upload Material).,00:00:00,0,0,,,,0

04/11/2014 06:40:00,LPR_New,Error,1,USPHND0088,LPR_New,Upload Material,,Executed as user: nestle\ussqldbserver. ...00.5324.00 for 32-bit Copyright (C) Microsoft Corp 1984-2005. All rights reserved.
Started: 6:40:00 AM Error: 2014-04-11 06:40:00.39 Code: 0xC001700A Source: Description: The version number in the package is not valid. The version number cannot be greater than current version number. End Error Error: 2014-04-11 06:40:00.39
Code: 0xC0016020 Source: Description: Package migration from version 3 to version 2 failed with error 0xC001700A "The version number in the package is not valid. The version number cannot be greater than current version number.". End Error Error: 2014-04-11 06:40:00.39 Code: 0xC0010018 Source: Description: Error loading value "3" from node "DTS:Property". End Error Could not load package "\usphnd0088\dataxfer\LPR\LPR New\UploadMaterial.dtsx" becau... Process Exit Code 5. The step failed.,00:00:00,0,0,,,,0

Answer 1

I had the same problem. here is how I easily solved it without messing with Visual studio. Of course the management studio on my desk is the latest version so when I exported/Imported using my management studio i had the error.

1. Actually Remote desktop into the legacy server and export the SSIS Project from that version of management studio.
2. While on the legacy server connect to the destination server of the same version and import.
3. I also found some fancy stuff where I had some aliases in the configuration manager aliasing some decommissioned servers.
4. One of the aliases was using Named pipes, that protocol was turned off on the destination so I turned that protocol on.
5. Did step 3,4 for both the 32 bit and 64 bit, and of course RDP'd into the destination server to make those changes.

Answer 2

To provide a newer answer, using SQL Server Data Tools 2015, you can set the Deployment Target Version for your integration project to 2012, 2014 or 2016 (It defaults to 2016 and will result in version number errors on 2012/2014 DBs until you set it correctly). I successfully deploy SQL 2012 integrations now from SSDT 2015 after setting to "SQL Server 2012".

Answer 3

Have you checked what version of BIDS the project file was built in? This happens when the sql server agent's version is different from the one used to build the project that the SSIS package lives in.

There is a suggestion to rebuild the project in the correct version of BIDS that matches the server agent used to run the job. One other option is to set the location/path of the DTEXEC file you want to use (depending on which version you are using).

References: MSDN / Package migration from version 3 to version 2 failed with error 0xC001700A. The version number in the package is not valid. The version number cannot be greater than current version number.

Answer 4

Per this blog: http://blogs.msdn.com/b/jason_howell/archive/2014/09/30/ssis-error-when-deploying-from-vs-2013-to-ssisdb-in-sql-2012.aspx

The underlying cause is that currently (Sept 2014 timeframe) SSDT BI 2014 for Visual Studio 2013 does not support SSIS packages for SQL Server 2012.

It is a common feature request, and the product group is well aware of the demand.

http://connect.microsoft.com/SQLServer/feedbackdetail/view/944882/ssdt-bi-2014-backward-compatibility-for-ssis-2012

At present SSDT for VS 2013 only works with SQL Server 2014. You have to use SSDT-BI for Visual Studio 2012 with SQL Server 2012 SSISDB.