1

I have an issue that looks like this:

I have an SSIS package which was using the 'Online Federation' connection type and I changed it to OAuth. After this I rebuild the project and went to sql server to Deploy the new .ispac file and it was unsuccessful because of the versioning as I guess from the error log.

Data Flow Update Currencies:Error:
Microsoft.SqlServer.Dts.Pipeline.ComponentVersionMismat
chException: The version of Update Currencies is not
compatible with this version of the DataFlow. [[The version
or pipeline version or both for the specified component is
higher than the current version. This package was probably
created on a new version of DTS or the component than is
installed on the current PC.]]
at
Microsoft.SqlServer.Dts.Pipeline.ManagedComponentHost.
HostCheckAndPerformUpgrade
(IDTSManagedComponentWrapper100 wrapper, Int32
lPipelineVersion)

I have searched all over the internet for this issue and there are several solutions, like:

  • changing the target version to the sql server version where I'm deploying it. (I made sure that this is correct but still no luck)

  • One more possible solution is to change the runtime from 64bit to 32bit. (I have also tried switching this value, but still no luck)

  • Rebuilding the project with different versions of VS. (I have tried with vs2015, vs2017 and vs2019. On my local machine the same package is Deployed successfully on the 2019 version of the sql server)

The package can't be Deployed on my local Sql server 2017 instance nor on the remote server where the old .ispac file was deployed.

The problem:

  • I don't know how the old package was built so because of this I can not Deploy my edited .ispac to the server.
  • I have the old .ispac file and I have the newly generated one. What can I do in order to get rid of the above mentioned issue ? I have really spent a lot of time on it.

Have you ever had such an experience ? If yes, what's your advice ?

Thanks

  • Did you change the target version of the project to 2017 in SSIS? – Thom A Apr 14 '22 at 15:26
  • @Larnu Yes, indeed I have changed the 'TargetServerVersion' to 'SQL Server 2017' from project properties within the Visual Studio – magicalKhachapuri Apr 14 '22 at 15:30
  • Did you rebuild the project after changing the target and then create the ispac? The fact that you managed to deploy it onto your 2019 instance, but not the 2017, suggests not; and you're trying to deploy a 2019 built project. – Thom A Apr 14 '22 at 15:30
  • @Larnu Yes, I did rebuild – magicalKhachapuri Apr 14 '22 at 15:31
  • Then the deployment should work. As i said, the fact it deployed to the 2019 instance, and that it specifically says, on the 2017 instance, that it's the wrong version strongly suggests that you are trying to deploy the 2019 built project to the 2017 instance. – Thom A Apr 14 '22 at 15:32
  • @Larnu No matter what I set as a target It still gets deployed in Sql server 2019 – magicalKhachapuri Apr 14 '22 at 15:34
  • It sounds like the ispac is being updated by the deployment tooling. https://stackoverflow.com/a/28098558/181965 Try using a version matching set of the `isdeploymentwizard.exe` Otherwise, I would like to see What is the target version of SQL Server? What does the the VS Project's Deployment specify? What mechanism are you using to deploy the .ispac? Where is the above failure/error log message reported? – billinkc Apr 14 '22 at 16:01
  • @billinkc The target version is set to SQL server 2017. I'm doing both manual deployment into the SQL server and also deployment from Visual studio. Error log is reported in both SQL and VS. I will check out isdeploymentwizard.exe and let you know what the results will be. – magicalKhachapuri Apr 14 '22 at 18:16
  • @billinkc oh I thought that isdeploymentwizard.exe was some other tool. Well how can I make sure the versioning of that ? – magicalKhachapuri Apr 14 '22 at 19:21
  • Find the path of the executable that is running. 110 SQL Server 2012, 120 SQL Server 2014, 130 SQL Server 2016, 140 SQL Server 2017, 150 SQL Server 2019. So, if you see `C:\Program Files (x86)\Microsoft SQL Server\140\DTS\Binn\ISDeploymentWizard.exe` that tells you the SQL Server 2017 tooling is handling it. – billinkc Apr 14 '22 at 20:50
  • @billinkc I was able to resolve the issue with rebuilding the project on the same server(machine) where I have the sql server and it was successful. I no longer have the errors about failed component upgrades. – magicalKhachapuri Apr 18 '22 at 07:32

0 Answers0