我们目前有一个使用 SSIS / C# 开发的解决方案。 SSIS 包（除其他外）有一个脚本任务，它使用在类库中开发的逻辑。此功能需要与 SSIS 包分开。
因为我们使用的是 SSIS 包，所以我知道编译后的 DLL 需要部署到 GAC，然后从脚本任务中引用。然而，这给我们带来了部署问题。
我们的自动化部署工具（正确地）自动增加 DLL 的版本号，然后将其发布到 GAC。然而，这会破坏 SSIS 包，因为它会尝试根据发布到开发机器 GAC 的版本号来访问 DLL。
对此我们唯一的解决方案是获取已编译的 DLL，手动修改 SSIS 包脚本任务，然后发布包。
似乎必须有更好的方法来做到这一点 - 有没有人遇到过这个问题并提出了更好的解决方案？或者我们的方法中是否有一些基本的东西需要改变（除了消除对 DLL 的需要）？
谢谢！
【问题讨论】：
标签： deployment ssis automation
好吧，经过大量研究，我从未真正想出一个令人满意的解决方案。最后，我能得到的最接近的解决方案是动态加载我的引用：
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 的一部分，尽管至少不依赖于版本号）。
在这里为未来的寻求者发布，但如果有人想出更好的东西，我仍然很想知道你是如何解决它的 - 在这里发帖，我会给你答案:)
【讨论】：
在我的情况下，只是调用 Assembly.LoadFile 不起作用。起作用的是这种方法：
在类构造函数中调用这个：
AppDomain.CurrentDomain.AssemblyResolve += new ResolveEventHandler(CurrentDomain_AssemblyResolve);
然后有这个方法，你需要的所有dll：
private Assembly CurrentDomain_AssemblyResolve(object sender, ResolveEventArgs args)
{
if (args.Name.Contains("libName.dll"))
return Assembly.LoadFile(System.IO.Path.Combine(_libraryFolder, "libName.dll"));
if (args.Name.Contains("libName2.dll"))
return Assembly.LoadFile(System.IO.Path.Combine(_libraryFolder, "libName2.dll"));
return null;
}
如果它们很多，您可能想用List<string> 重构它。
【讨论】：
我注意到我们的 SSIS/C# 组合存在类似问题。我们还依赖外部（对 SSIS）dll。在我们的例子中，必须将 DLL 复制到 100/DTS/Binn 目录以允许 SSIS 包在 Visual Studio 中工作，但是当我们尝试使用 SQL 包执行实用程序运行包时，我们会收到一个错误，影响到找不到该文件。它似乎并不表示版本问题，而是 Visual Studio 和包执行实用程序之间的 PATH 差异。即使在没有从 Visual Studio 调试的情况下运行包也可以。我将调查版本问题，看看这是否是我们系统的核心抱怨，但从记忆中我认为这是一个影响我们的文件未找到类型错误。我们正在使用 MSSQL 2008，如果这有影响的话。
【讨论】：
您确定这些共享 DLL必须部署到 GAC 吗？如果它们与 SSIS 包位于同一文件夹中，则框架应该可以发现它们，而无需将它们添加到 GAC。
有没有办法更新您的构建系统以避免版本号更改？如果这些程序集的代码没有变化，则无需更新版本号。
如果您无法避免版本增加，另一种选择是与共享程序集一起构建一个策略文件，并使用它在每次构建时将 SSIS 包“重定向”到新版本。
【讨论】：