Making your Existing Custom SSIS Extensions and Applications Work in Denali

Today’s post is from Rujin Cao – a developer on the SSIS team based in Shanghai. This article talks about the .NET assembly binding we include in our .exes by default, which makes migrating custom SSIS code to Denali a lot easier. Note that while this is a good work around, recompiling your code to target the Denali versions of the SSIS assemblies is still recommended.

Upgrading custom extensions and applications which used the SSIS object model from 2005 to 2008 required some code changes . One of the goals in SQL Server “Denali” was to make this process easier. In general, most .NET custom extensions (i.e. ones that use the ManagedDTS API ) will not need to be recompiled or require code changes, and most custom applications will just need to update their .exe.config file.

Custom SSIS Extensions

For custom SSIS extensions, we added four binding redirection rules in the *.exe.config of DTExec.exe, DTExecUI, dtshost.exe, DTSWizard.exe and DTUtil.exe to help redirect the runtime assemblies from version 10.0.0.0(in SQL Server 2008(R2)) to version 11.0.0.0(SQL Server “Denali”). Here it is (you can also see it in“%ProgramFiles%\Microsoft SQL Server\110\DTS\Binn\DTExec.exe.config” after installing Denali):

The four redirected assemblies are:

1. Microsoft.SqlServer.ManagedDTS
2. Microsoft.SqlServer.DTSRuntimeWrap
3. Microsoft.SqlServer.DTSPipelineWrap
4. Microsoft.SqlServer.PipelineHost

If you are using some other version 10.0.0.0 assemblies (for example, the 9.0.242.0 assemblies from SQL Server 2005), you might have to add more rules in the *.exe.config files to redirect them to the Denali version 11.0.0.0.

Custom SSIS Applications

For the custom SSIS application, the process is much similar. You can create one configuration file (i.e. *.exe.config) for the executable (if it doesn’t have one), and put the above redirect rules into configuration section, more details can be found here .