views:

361

answers:

2

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?

+1  A: 

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
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
Is it possible that .NET framework version differences affect this? I haven't checked into that.
Cade Roux
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
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
Both machines have 1.1, 2.0 and 3.0 and identical versions.
Cade Roux
+1  A: 

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