Partager via

64-bit references within an SSIS Script Component

  • Article

I was forwarded a question about SSIS Script Component on 64-bit, I think the answer may benefit others as well:

Currently we are referencing a 32-bit third party component in a script component and running the SSIS package in 32 bit mode on a X64 bit server. Recently, the third party vendor has made available a 64-bit version of this component and we would like to reference this version in our script task in order to run the package in 64-bit mode.

What we are experiencing is that script component “Add Reference” dialog only browses to the 32 bit framework folder and not the framework64 folder.

Is it possible for the script component to reference a 64-bit assembly?

First a small explanation for those puzzled by the question. Most .NET assemblies are platform neutral, meaning the same assembly can be run on 32-bit and 64-bit platform. For neutral assemblies the problem does not occur at all. But some assemblies may be created for 32-bit or for 64-bit platform only, or a separate version of the assembly is built for each platform. E.g. if some external unmanaged code (usually a COM component) that the assembly uses is available on 32-bit platform only, you should mark your assembly as 32-bit only to prevent attempts to use it on 64-bit. If the interface of dependency is different between the platforms, you might build a separate version for each platform. E.g. Microsoft does this for System.Transactions assembly.

Now back to the question: can one use 64-bit version of external assembly in Script Component?

Well, you can't reference the 64-bit assembly in the Script editor (VSA), because it is 32-bit application. But let's look at how .NET loads depedent assemblies from GAC: it first tries to load current platform-specific version, if it is not found it tries MSIL (neutral) version. The "current" here means determined by bitness of the current process. It does not matter if the assembly was compiled with 64-bit or with 32-bit version.

So you should reference the 32-bit version of the assembly during design time. At runtime .NET will choose the appropriate version for the current process from those available in the GAC. 32 process will use 32-bit version of the assembly, and 64-bit process will use 64-bit version. Goal achieved.

This is similar to how SSIS uses OLEDB providers – you reference 32-bit one at design time, and we pick up matching 64-bit OLEDB provider at runtime if the package is executed in 64-bit process.

Note that this is only possible if you have both 32-bit and 64-bit versions of external assembly. Also since the script task keeps only one platform neutral assembly for its own code, the metadata for 32-bit and 64-bit assemblies should be the same. I.e. they should have the same assembly name and version, define the same class names, function prototypes, etc.

Comments

  • Anonymous
    October 05, 2007
    Any idea why a script task might fail with error "Precompiled script failed to load. The computer that is running the Script Task does not have a compiler capable of recompiling the script." on a 64-bit server? The server has SQL 2005 SP2, and the script was precompiled on a 32-bit machine. The error does not happen to script transformations in data flow. Thanks.