2009-12-07 51 views
5

我们目前拥有使用SSIS/C#开发的解决方案。 SSIS包(除其他外)具有使用类库中开发的逻辑的脚本任务。此功能需要与SSIS包保持独立。自动部署混合SSIS/DLL解决方案

因为我们使用的是SSIS包,所以我知道编译后的DLL需要部署到GAC,然后从脚本任务中引用。但是这给我们造成了一个部署问题。

我们的自动部署工具(正确)会自动增加DLL的版本号,然后发布到GAC。但是,这会破坏SSIS包,因为它会根据它们发布到开发机器GAC的版本号尝试访问DLL。

我们唯一的解决方案是获得编译的DLL,手动修改SSIS包脚本任务,然后发布包。

似乎必须有一个更好的方式来做到这一点 - 有没有人遇到这个问题,并提出更好的解决方案?或者,我们需要改变的方法有一些基本的东西(除了不需要DLL)?

谢谢!

回答

8

好吧,经过大量研究,我从来没有真正想出一个令人满意的解决方案。到底是最接近我能得到了一个解决方案,我动态加载我引用:

Dim rsAssembly As Assembly = Assembly.LoadFile("path from config file") 
    Dim rsType As Type = rsAssembly.GetType("class name from config file") 
    Dim obj As Object = Activator.CreateInstance(rsType) 

这让我创造我所需要的对象(但值得注意的是,任何其他相关的引用也需要动态地加载或GAC的一部分,尽管至少没有版本号的依赖)。

这里发布对未来的求职者,但如果有人想出了更好的东西我还是会很好奇,想知道你是怎么解决它 - 在这里后,我会存入你的答案:)

0

您是否确定将那些共享DLL 必须部署到GAC?如果它们与SSIS包位于同一个文件夹中,则无需将它们添加到GAC中即可在框架中发现它们。

有没有办法更新您的构建系统以避免版本号更改?如果这些程序集的代码没有更改,则不需要更新版本号。

如果您无法避免版本增量,另一种方法是与共享程序集一起构建策略文件,并使用该文件将SSIS程序包“重定向到”每个版本的新版本。

+0

我拥有的信息是SSIS包必须部署到GAC,如果不是,那么很好 - 但你确定吗?内部编号 - 我想我们可以,但这个想法让我有点不舒服。我之前没有使用过Policy文件,我会去看看它们,谢谢 – Chris 2009-12-07 16:53:25

+0

我还没有试过一个带外部依赖项的SSIS包,所以我不确定。应该相当容易地建立你的软件包的依赖模拟和做一个快速的抽烟测试... – 2009-12-07 17:28:33

+0

嗨戴夫 - 我一直在调查政策文件,因为他们有关的SSIS解决方案,我真的不明白我会引入一个而不会创建另一个依赖关系。我可能会错过一些东西,但如果您有任何关于如何将它们用于SSIS包的其他信息,将非常感谢! – Chris 2009-12-07 17:38:05

1

我已经注意到与我们的SSIS/C#混合类似的问题。我们还依赖于外部(对SSIS)dll。在我们的例子中,DLL必须被复制到100/DTS/Binn目录中,以允许SSIS包在Visual Studio中工作,但是当我们尝试使用SQL包执行实用程序运行包时,我们得到一个错误无法找到该文件。它似乎并不表示版本问题,因为Visual Studio和Package Execution Utility之间的PATH不同。即使从Visual Studio运行程序包也无需调试。我将研究版本问题,看看也许这是我们系统的核心投诉,但是从内存来看,我认为这是一个文件未找到的类型错误,影响了我们。如果这有所作为,我们正在使用MSSQL 2008。

+1

在后续步骤中,我能够通过将DLL复制到主机来成功执行包机器windows \ assembly目录。显然这是难以捉摸的GAC位置?无论如何,我们的部署机制并非如此自动化,所以也许这就是为什么我们没有版本问题。一旦我将dll复制到windows \ assembly目录,包运行完成。 – Travis 2010-02-16 21:06:33

+1

嗨特拉维斯 - 是的,这是GAC的位置,不确定对SQL 2008的限制,但如果它有帮助,我可以为你确认,在SQL 2005的部署服务器上,DLL必须部署到GAC :( – Chris 2010-07-05 09:34:29