Recommendable stuff...

Tuesday, March 25, 2008

Script Task Precompiling bahaviour , custom references and side by side execution

If you have a script task that references a custom assembly, you would know by now that the custom assembly needs be in the GAC. However the GAC copy is only used during runtime.

For development, you'll also need to have the custom reference in the Microsoft.Net framework directory, ex C:\Windows\Microsoft.Net\Framework\v2.0.50727\.

Now what if you have two versions of the SSIS package, and two versions of the custom assembly, and these need to be developed and executed side by side. How do we handle this? See below for some notes:

Development
1. Make sure the correct version of the custom assembly you want your SSIS Script Task/Component to work with is in the .net framework directory. What I mean is, if you're working on v1.0 of your SSIS package, and the script tasks are supposed to reference v1.0 of your custom assembly, make sure v1.0 of the custom assembly is in the .net framework directory.

If are working with v1.0 SSIS package, you have v1.1 of the custom assembly in .net framework directory, and you open the script task, it will automatically pick up the framework directory version and if you have turned on precompiling, it will compile against the v1.1, and during runtime, will look for that version in GAC. The same works vice versa.

2. When you're done with v1.0 SSIS package, and start work on v1.1, copy the v1.1 of the custom assembly to the .net framework directory first, before opening your package, and especially before opening your script tasks.

Set a post build event on your custom assembly's project to automatically copy the built assembly to GAC AND copy to your .net framework directory. This ensures you're always developing your SSIS package against the correct custom assembly.
Example post build event:

"C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\Bin\gacutil.exe" /if "$(TargetPath)"
copy /Y "$(TargetPath)" "C:\Windows\Microsoft.Net\Framework\v2.0.50727\$(TargetFileName)"

Runtime
1. If precompiling is turned off, the custom assembly has to be placed in the .net framework directory the SSIS Script task will compile at runtime, against the version in .net framework directory.

2. If you have v1.0 and v1.1 SSIS packages deployed on a machine, and v1.1 of custom assembly is in the .net framework dir, and their script tasks are not precompiled, BOTH SSIS packages will compile against v1.1 of your custom assembly. If your v1.1 custom assembly is not backward compatible with v1.0, your v1.0 SSIS package could break at runtime.

Turning on precompiling eliminates the need to have the custom assembly in the framework directory, and multiple versions of SSIS packages can run simultaneously.

0 ppl said stuff:

Get the new version of Firefox!