Cause of SSIS Custom Dataflow Component Error - Cannot be upgraded
Asked Answered
T

7

6

I have a very simple component which trims all leading and trailing spaces from (read/write) strings in a pipeline. As far as I can see, I only have one binary of this dll on my development machine. I am transferring it to another development machine and registering it in the GAC, but when I open a package I copied to the second machine, I get this warning:

Error 1 Validation error. Data Flow Task: DTS.Pipeline: The component metadata for "component "TrimColumnsComponent" (1909)" could not be upgraded to the newer version of the component. The PerformUpgrade method failed. LD_CXSUM.dtsx 0 0

I have the component in the toolbox, and I can drag another one onto the dataflow canvas and it doesn't appear to have any problem.

This is SQL Server 2005 and Visual Studio 2005 on both machines.

On the second machine, I can create a package from scratch and it will load on the machine that built the component (but the icon is the standard user component icon, the same as it was on the second machine). If I create a package from scratch on the build machine, it has the correct icon, but it gives the upgrade message on the non-build machine. The files are identical in the components directory, they have the same component class id and they are registered in the GAC.

I have checked the dtsx files manually by inspecting the XML and in packages created on the build machine and the non-build machine, the class id and public key are identical between machines.

What can cause this?

Titty answered 28/7, 2009 at 14:34 Comment(2)
Are you going from 2005 to 2008 or vice versa? I've seen this hiccup a lot if that's the case.Wilhoit
SQL Server 2005 and VS 2005 on both machines.Titty
W
3

Generally this means that the component was upgraded after the package was saved, and so it's at the wrong version number. You'll have to re-add the component, unfortunately.

You may be able to save the package as a new version and try migrating that. This may solve the problem of the automatic upgrade being called (and subsequently failing).

Wilhoit answered 28/7, 2009 at 14:53 Comment(5)
This particular package did not exist at the time the component was created, so I'm not sure it has ever seen any other versions of the component (which last changed 7 months ago). I will try some experiments with a new package from one machine going to the other.Titty
Is it possible that .NET framework version differences affect this? I haven't checked into that.Titty
That could absolutely be the case. If you're going from .NET 3.5 to .NET 2.0, the component may be calling some libraries that don't exist or expecting newer versions of the .NET libraries.Wilhoit
Well the component doesn't do that much (and new instances dragged onto the canvas work), but it's possible that the machines differ slightly.Titty
Both machines have 1.1, 2.0 and 3.0 and identical versions.Titty
A
5

I had the same issue, it was a wrong set of target server version. You can check it by right clicking the project in the Solution Explorer and selecting Properties. Go to Configuration properties, General, and the TargetServerVersion option will be displayed. You can changed this to your target.

Ataman answered 14/11, 2019 at 16:21 Comment(1)
This worked perfectly for me, I switched from SQL Server 2017 to 2019 and that did the trick.Honky
W
3

Generally this means that the component was upgraded after the package was saved, and so it's at the wrong version number. You'll have to re-add the component, unfortunately.

You may be able to save the package as a new version and try migrating that. This may solve the problem of the automatic upgrade being called (and subsequently failing).

Wilhoit answered 28/7, 2009 at 14:53 Comment(5)
This particular package did not exist at the time the component was created, so I'm not sure it has ever seen any other versions of the component (which last changed 7 months ago). I will try some experiments with a new package from one machine going to the other.Titty
Is it possible that .NET framework version differences affect this? I haven't checked into that.Titty
That could absolutely be the case. If you're going from .NET 3.5 to .NET 2.0, the component may be calling some libraries that don't exist or expecting newer versions of the .NET libraries.Wilhoit
Well the component doesn't do that much (and new instances dragged onto the canvas work), but it's possible that the machines differ slightly.Titty
Both machines have 1.1, 2.0 and 3.0 and identical versions.Titty
V
2

Are you 100% positive the copy of the component in the GAC matches the copy in the Program Files\Microsoft SQL Server\90\DTS\PipelineComponents folder? The GAC copy is used at runtime, and the copy under PipelineComponents is used by the VS IDE. If you are running on an x64 machine, I'd make sure you copy it to the PipelineComponents folder under both the regular Program Files folder and the x86 folder.

Vagary answered 10/8, 2009 at 0:18 Comment(2)
On all machines, we are using the component from the SSIS/BI IDE and not using dtexec. The GAC copy seems to be the same - it has the same public key. Now the one on the machines which were installed later has a modification datae in the GAC of when it was added to the GAC.Titty
It's not necessarily the public key, you can change the version of a component without changing the key. I'd recommend un-installing the component from the GAC, copying it to the appropriate Program Files folder, and then reinstall it into the GAC, pointing gacutil to the copy in the Program Files folder to make sure it's the same version.Vagary
S
2

I had the same issue, the way round this for me was to deploy the whole project rather than an individual package. This resolved the issue and enabled the package to run as normal.

Stefaniestefano answered 12/12, 2017 at 14:55 Comment(0)
M
1

Including Client Tools SDK and Client Tools Backward Compatability in the SQL Server installation solved the upgrading problem for me.

Meditate answered 3/3, 2014 at 9:39 Comment(0)
A
1

I had the same problem and my solution is the same as the one from @AppleG. The issue was generated by deploying one single package rather than the whole project. The project was deployed earlier by another developer, most probably with a slightly different version of Visual Studio or the Deployment Wizard. Then I deployed later only one package from my VS.

In conclusion, deploying the whole project again resolved the issue.

Alary answered 26/10, 2018 at 19:38 Comment(0)
Z
0

I created a new Project and imported a SSIS package from a server. After deploying the package, I had the same issue. Changing the Target Server version as Imran suggested above by right clicking the project in the Solution Explorer and selecting Properties > Configuration Tab > Target Server Version, fixed the issue for me. In my Case the SSIS package was set to SQL Server 2019 whilst my SQL Server is version 2017.

Zhdanov answered 1/11, 2023 at 11:36 Comment(0)

© 2022 - 2025 — McMap. All rights reserved.