Katmai - Custom components and upgrade

Katmai - Custom components and upgrade

  • Comments 8

(Note, when I use the word "components" in this post, I'm referring to all extensible items, including tasks, pipeline components, foreach enumerators, loggers and connections)

The first major change I worked on as part of the SSIS team was re-versioning our components for Katmai. This included:

  1. Changing interface names from 90 to 100 (IDTSxxxx90 becomes IDTSxxxx100)
  2. Updating the versions of our managed components (typically 9.0.242.0 to 10.0.0.0)
  3. Generating new GUIDs for our COM components
  4. Incrementing version numbers of the COM ProgIds

These changes were painful, but necessary for the new version and to support side by side scenarios where you have both SQL Server 2005 and Katmai installed.

Because the current SSIS package format uses strong assembly names, GUIDs and ProgIds to reference most of the components, SQL Server 2005 packages will need to be upgraded in Katmai. Currently we take care of the upgrade behind the scenes by doing a name mapping lookup on-the-fly when you run or load a package, but in a future CTP we will have our full upgrade solution in place.

The solution in the current CTP will work for packages which use the stock components that ship with SSIS, but running packages which contain custom or third party components will require some manual steps. These components will need to be recompiled with the new interfaces and assemblies before they can be used in Katmai.

I should note that we're currently working hard to ensure that in the future, upgrading components and packages will be as painless as possible. I'll be able to talk about the plans once they appear in a CTP.

Here are the steps you'll need to do to get your custom component working in Katmai. (Note, all of this information is also in the Katmai CTP readme)

Assembly references

Managed components will need to update their references to SSIS assemblies to point to the Katmai versions.

Microsoft.SqlServer.Dts.Design
Microsoft.SqlServer.DTSPipelineWrap
Microsoft.SqlServer.DTSRuntimeWrap
Microsoft.SqlServer.ManagedDTS
Microsoft.SqlServer.PipelineHost

All versions should now be 10.0.0.0.

Rename interfaces

All IDTSxxxx90 interfaces have been renamed to IDTSxxxx100, and will need to be changed before you can recompile. You can use the following regular expression in visual studio's Find/Replace dialog to do this:

FIND: {[:b(,.<_]}{IDTS[A-Za-z_#]+}90{[:b\[\*>,.);]}
REPL: \1\2100\3

Versioning

If you're changing the version of your component (if you want it to supporting running side by side, for example), you'll have to manually edit (or recreate) your packages to use the new assembly version/guid/progid. (Note, this process will be improved in an upcoming CTP).

Deploy

Rebuild you component. Note that your files should now go under one of the subdirectories under "%ProgramFiles%/Microsoft SQL Server/100/DTS" (instead of "%ProgramFiles%/Microsoft SQL Server/90/DTS").

Leave a Comment
  • Please add 4 and 5 and type the answer here:
  • Post
  • We have a custom SSIS pipeline component we developed to access WCF web services and import data.  This was written for Sql 2005 and visual studio 2005.

    I have quite a few packages using this component, with many tasks, components, etc. downstream from the component in the packages.

    I'd like to know if it's possible to upgrade the component that is already in the package without deleting the old one from the toolbox, re-adding the new one, then adding the new component to the existing package, deleting the link from the all the downstream package stuff...  It's quite a bit of work to reestablish all the meta data in the package after I upgrade the component.  I looked at the source code (xml) for the package and couldn't find anything useful to change (to help).  I did re-gac after the upgrade and VS did no "automagically" recognize the new upgraded component.

    pain, suffering......

    any ideas?

  • If you don't change the version number / assembly name of the component, it should be picked up automatically without any changes.

    If the version/GUID/ProgID have changed, you should be able to manually edit the package XML. Look for the <component> entry for your component. For managed components, look for the UserComponentTypeName attribute - this should be the strong assembly name for your class. As long as your metadata hasn't changed, changing this to the new value should fix your problem.

  • The introduction of new SSIS features in the SQL Server 2008 release and beyond made it necessary for

  • The introduction of new SSIS features in the SQL Server 2008 release and beyond made it necessary for

  • Custom Extensions in SQL Server 2008

  • The SQL Server 2008 Books Online page in which we describe the steps for upgrading and redistributing

  • Hiya Matt,

    I'm converting a v2005 component and its got a call to the following method:

    IDTSOutputColumn100.SetDataTypeProperties.

    In the code I've inherited the first parameter is an integer however now the method is expecting something from the DataType enum.

    THis is easy to fix but nonetheless, do you know of any other gotchas like this?

    cheers

    Jamie

  • Ignore the previous comment!! The code I'm changing was generated form Reflector - hence there's an integer where an enum is expected!

    sorry!

Page 1 of 1 (8 items)