我们有一个 SSIS 2005 包，安装在中央服务器上并从多个位置调用。
该包使用脚本任务来调用我用 C# 编写并安装到中央服务器上的 GAC 中的 .NET DLL。
当我从安装了该包的服务器调用 SSIS 包时，一切都很好。
当我使用 SQL Server 代理从远程服务器调用该包时，作业失败并报告找不到 DLL。
为了测试发生了什么，我在远程服务器上安装了 dll，并且打包成功。因此，虽然该包安装在一台计算机上，但当使用 SQL Server agend 从另一台计算机调用它时，它实际上在调用计算机上执行，并且调用计算机必须满足所有依赖项。
该包将从数十台服务器中调用，其中许多服务器我无法控制。
有没有一种方法可以让我安装、配置、编译、调用或以其他方式对该包的构建或执行方式执行某些操作，以便它将从安装该包的计算机上的 GAC 调用 DLL？
We have a SSIS 2005 package that is installed on a central server and is called from multiple locations.
This package uses a script task to call a .NET DLL which I wrote in c# and installed into the GAC on the central server.
When I call the SSIS package from that server on which the package is installed everything is fine.
When I call the package from a remote server using SQL Server Agent, the job fails reporting that it cannot find the DLL.
Just to test out what is happening I installed the dll on the remote server and the package succeeded. So it appears that although the package is installed on one machine, when it is called from another using SQL Server agend it actually executes on the calling machine and it is the calling machine that must satisfy all the dependencies.
This package is going to be called from dozens of servers, many of which I do not have control over.
Is there a way in which I can, install, configure, compile, call or otherwise do something to the way this package is built or executed so that it will call the DLL from the GAC on the machine where the package is installed?
发布评论
评论（1）
不幸的是，您需要更改您的设计，因为 SSIS 包存储就是存储。执行始终在调用包的机器上进行，并且所有引用都被视为相对于该机器。
一种选择是向 SSIS 包添加一个任务，该任务在调用计算机的 GAC 中复制并注册 DLL - 但如果您无法控制某些执行计算机，则不能保证执行 SQL 代理帐户将拥有有足够的权限来注册 DLL。
另一种解决方案是将 DLL 代码转换为 SSIS 包内的脚本任务。这意味着将代码从 C# 转换为 VB，并且根据代码的详细信息，这可能并不简单。
如果没有有关包的用途和 DLL 功能的更多详细信息，则很难评估其他替代方案，但您可以考虑是否可以对包进行参数化以使其始终从存储服务器运行。
Unfortunately, you will need to change your design, since SSIS package storage is just that - storage. Execution always takes place on the machine from which the package is called, and all references are treated as relative to that machine.
One option is to add a task to the SSIS package which copies and registers the DLL in the GAC of the calling machine - but if you do not have control over some of the executing machines, there is no guarantee the executing SQL Agent account will have sufficient rights to register a DLL.
Another solution would be to convert the DLL code into a script task inside the SSIS package. This would mean converting the code from C# to VB, and may be non-trivial depending on the detail of your code.
Without more details of the purpose of the package and the functionality of the DLL it's difficult to evaluate other alternatives, but you could consider whether it would be possible to parameterise the package to enable it always to run from the storage server.