我的假设是,SSIS包的脚本组件最终被编译成一个程序集中的某个地方 – 这很可能是因为我想象的C#代码不能运行没有一些编译它的第一.所以在理论上,如果这些程序集最终被缓存,而不是立即被覆盖(由于某种原因),这将解释这个问题.
使我认为我的理论是正确的唯一的“证据”是如果我在某种程度上继续运行包,它将突然转向新的代码.
但是,到目前为止,我还没有找到为什么以及如何发生这种情况,是否可以帮助？
更新：
MSDN说：“与早期版本不同,您可以指出脚本是否已预编译,所有脚本都在sql Server 2008集成服务(SSIS)和更高版本中预编译. – 如果通过预编译,它们意味着,而不是实际的包,预编译版本运行(我认为这是因为程序包本身似乎没有被编译,因为代码在记事本中可见),必须有一种方法强制引擎覆盖预编译程序集…但如何？
更新：
SSIS的四个核心组件之一是sql ServerIntegration Services服务,它是Windows服务.显然,此服务将缓存组件/任务元数据,以便SSIS运行时引擎可以轮询缓存以查看已安装的内容,这可能有助于加快程序包加载时间.但是,如果软件包存储在文件系统(不在sql Integration Services中)并由代理作业执行,则代理作业将使用64位版本的DTEXEC来执行软件包.我还没有发现任何缓存会涉及到的证据,但肯定有选项可以在执行的验证阶段检查许多参数,如版本号 – 可能是出于某种原因.
解决方法
SELECT name,verbuild FROM msdb.dbo.sysssispackages WHERE name LIKE '%bla%'
(根据需要调整WHERE子句,以查找您的包.不要将“SELECT * FROM msdb.dbo.sysssispackages”包含在其中一列中的包XML).
并在Visual Studio中打开包,然后右键单击包的背景,然后从上下文菜单中选择“属性”.看看VersionBuild.它应该匹配上面的SELECT的数字！
我知道这不是您的问题的实际解决方案,但它可能有助于确定问题的原因.如果数字较旧,则表示您的程序包部署不起作用.
