Skip to main content

Referencing the Same Custom Script Task in SSIS with Biml

Why This Pattern Matters​

A Biml project often defines a custom script task once in its own file and references it from multiple places. When the same script task is added to a single package more than once, the package builds without warnings but throws a confusing runtime error during debug execution in Visual Studio. The cause is a name collision in the compiled .NET assembly that backs the script task.

What Goes Wrong​

SSIS compiles the body of a script task into a .NET assembly that is stored with the package. The compiled name comes from the script task's 'ProjectCoreName' property. If two script tasks in the same package share the same 'ProjectCoreName', their compiled assemblies share an identifier, and the SSIS engine cannot tell them apart at runtime. The error surfaces only when the package executes, which makes it easy to chase the wrong cause for hours.

The Fix​

Give every script task instance a unique 'ProjectCoreName'. The cleanest way is to drive 'ProjectCoreName' from a variable that the calling Biml file passes in. A code nugget inside the script task's Biml file substitutes the variable into 'ProjectCoreName', so each call site produces a distinct identifier.

The Biml file containing the script task accepts a variable, for example 'callerName', and writes it into the 'ProjectCoreName' attribute:

<#@ property name="callerName" type="string" #>
<ScriptTask Name="ProcessRow_<#=callerName#>" ProjectCoreName="ScriptTask_<#=callerName#>">
  <ScriptTaskProjectReference ScriptTaskProjectName="MyScriptTaskProject" />
</ScriptTask>

The calling Biml file passes a different value for 'callerName' on each invocation, for example the column name being processed or a stage identifier:

<#=CallBimlScript("ProcessRowScriptTask.biml", "OrderId")#>
<#=CallBimlScript("ProcessRowScriptTask.biml", "CustomerName")#>
<#=CallBimlScript("ProcessRowScriptTask.biml", "OrderTotal")#>

Each generated 'ScriptTask' element ends up with its own 'ProjectCoreName' value, the SSIS engine sees three distinct script tasks, and the runtime error disappears.

Summary​

When the same custom script task appears more than once in a single SSIS package, parameterize 'ProjectCoreName' so each instance gets a unique identifier. The cost is one extra Biml property; the payoff is avoiding a runtime error that gives no useful clue about its cause.