June 6, 2008 at 1:35 pm
I'm trying to debug a problem we're having with a script task in an SSIS package that is deployed to an application server. This package is being executed via a batch file calling DTEXEC, but the package's script task fails unless the DLL it references is located in the appropriate .NET Framework folder. My understanding is that:
-- .NET DLL's to be referenced by script tasks need to be in the .NET framework folder on the developer's machine
-- Script tasks can be set to PreCompileScriptIntoBinaryCode, which should eliminate the need to put the .NET DLL in the .NET framework dir path on the server. Rather the GAC'd DLL is available to the executing package, no matter where it exists.
However, for this package at least, we're seeing this error if the package is executed and the DLL is not in the .NET framework dir path:
dts://Scripts/ScriptTask_8fa1ed3593f743599e3584bbe1c3370a/ScriptMain(29) : error BC30002: Type 'component' is not defined
The workaround is obvious, but I can't get over the thought that it shouldn't be necessary. I haven't been able to find much documentation on where external DLL's used by script tasks need to be located for deployed packages, and/or if SSIS packages access info from the GAC. So, any help anyone can offer is great!
June 6, 2008 at 1:38 pm
The only thing I have read about this is what you have already mentioned. The DLL needs to be in the .NET framework folder on the developer's machine so it can be added to the script and in the GAC to be debugged and just in the GAC on the SQL Server.
Jack Corbett
Consultant - Straight Path Solutions
Check out these links on how to get faster and more accurate answers:
Forum Etiquette: How to post data/code on a forum to get the best help
Need an Answer? Actually, No ... You Need a Question
June 6, 2008 at 1:48 pm
Sorry, let me clarify-- the package is not on a SQL Server per se (no databases), it's on a shared application server that has SSIS running/certain SQL Server 2005 components installed. Other packages do run successfully on this server, so I don't think it's a general server configuration issue.
June 6, 2008 at 1:54 pm
I use SQL Server in a generic manner when referring to the physical server on which any SQL Server components reside (SSIS, SSRS, SSAS, Database Engine). So in this case substitute SSIS server.
Jack Corbett
Consultant - Straight Path Solutions
Check out these links on how to get faster and more accurate answers:
Forum Etiquette: How to post data/code on a forum to get the best help
Need an Answer? Actually, No ... You Need a Question
June 9, 2008 at 6:41 am
The .dll needs to be in the .Net framework folder and registered in the GAC on any machine that will be executing the package.
If you open the package and run it through BIDS, the machine BIDS is running on needs the .dll. If you are running it through the SQL Agent, the server the Agent is running on needs the .dll.
I sometimes create a step in packages that copies the .dll's and the GAC utility and registers them on the machine running the package - just to be sure.
June 9, 2008 at 7:31 am
Thanks, Michael! It's good to have a clear answer on this, though it's a surprise, in a way. I'll keep your "extra step" suggestion in mind, too.
Thanks again!
June 9, 2008 at 7:39 am
To be perfectly clear, the .dll does not HAVE to be in the .Net framework folder on the server if you only run the package through the job agent. The .dll could be registered in the GAC and in any folder in this case, but if you ever want to troubleshoot something that is only happening on the server, you cannot run the package on the server in BIDS - it turns into a big pain.
So, put the .dll in the same place on every machine - the .Net framework folder - and register it there in the GAC.
MS claims to have fixed this in 2008 but I have not tried it yet.
June 9, 2008 at 7:45 am
Actually, our experience with this particular package has been the opposite -- the DLL had to exist in the .NET framework folder in order for dtexec to run it successfully. The DLL is part of a set of corporate .NET DLL's, so it normally exists in a different path, and is GAC'd. However, the package itself can only run successfully via dtexec if a copy of this DLL is also in the .NET Framework folder.
June 9, 2008 at 7:58 am
You could be right - my memory may be backwards on this, but I thought it was on the workstation that it needed to be in the framework folder. Regardless, I gave up long ago and started putting them in the same place everywhere to eliminate the confusion. It has also simplified my install packages - I just use the configured framework folder and I am done.
MS did a pretty bad job of making all of this work. With 2008 being able to reference a web service, I'll need half as many .dll's also.
June 9, 2008 at 9:31 am
Re: consuming a web service from inside a script task, you can generate the proxy code from the WSDL & reference it in your script task, which is nicely documented here: [/url]
I've tested this a bit, and so far, so good, though you likely would need to set the proxy code to use a variable for the URL to make it easier to migrate across environments.
February 3, 2009 at 1:15 pm
The Assemby does not need to be in the GAC. If you want to use an assembly, without a strong name, on your SQL SSIS Packages then all you need to do is copy to some respective locations. Using the default installation paths of Windows and SQL, they would be the following:
For Design:
C:\Windows\Microsoft.NET\Framework\v2.0.50727
For Run Time
C:\Program Files\Microsoft SQL Server\90\DTS\Binn
Viewing 11 posts - 1 through 10 (of 10 total)
You must be logged in to reply to this topic. Login to reply