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?

Cade Roux
  • 88,164
  • 40
  • 182
  • 265

6 Answers6

4

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.

Imran Sh
  • 1,623
  • 4
  • 27
  • 50
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 1.

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).

Eric
  • 92,005
  • 12
  • 114
  • 115
  • 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. – Cade Roux Jul 28 '09 at 14:56
  • Is it possible that .NET framework version differences affect this? I haven't checked into that. – Cade Roux Jul 28 '09 at 14:57
  • 1
    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. – Eric Jul 28 '09 at 15:02
  • 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. – Cade Roux Jul 28 '09 at 15:16
  • Both machines have 1.1, 2.0 and 3.0 and identical versions. – Cade Roux Jul 28 '09 at 21:11
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.

AppleG
  • 21
  • 1
1

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.

John Welch
  • 46
  • 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. – Cade Roux Aug 10 '09 at 13:12
  • 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. – John Welch Aug 10 '09 at 14:46
1

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

niklasolsn
  • 303
  • 5
  • 10
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.

Zsombor Zsuffa
  • 121
  • 5