关于SSIS 2016中C#脚本的编译与缓存机制 #

• 首次运行脚本任务时，SSIS会编译你的C#代码，生成的.NET程序集会被缓存到本地临时目录（比如系统临时文件夹下的VSTAProjects相关子目录）。
• 后续运行时，只要脚本代码、脚本任务的配置（比如引用的变量列表）没有修改，且缓存的程序集没有被清理（比如SQL Server服务重启、临时文件被系统自动清理），SSIS会直接复用缓存的程序集，不会重新编译。
• 触发重新编译的场景包括：修改了脚本代码、调整了脚本任务的变量引用配置、缓存的程序集丢失或损坏、SSIS服务进程重启。

为什么SSIS 2012没报错，2016却出现赋值错误？ #

从你给出的代码片段来看：

Variables.ContainerDisable100 = C100; 
Variables.ContainerDisable101 = C101; 
Variables.ContainerDisable102 = C102; 
Variables.ContainerDisable102 = C103; // 这里应该是ContainerDisable103

这个问题的核心是SSIS 2012和2016的脚本任务验证/编译机制存在明显差异：

• SSIS 2012使用的是较旧版本的VSTA（Visual Studio Tools for Applications）工具链，对脚本中变量引用的检查相对宽松。比如，即使你没有给ContainerDisable103变量赋值（或者错误地重复覆盖了ContainerDisable102），只要相关变量在包中存在，且脚本没有语法错误，2012可能不会触发运行时错误——甚至如果ContainerDisable103是可选变量，可能完全不会被校验。
• SSIS 2016升级了VSTA版本，对脚本的编译和运行时验证更严格：
  1. 如果ContainerDisable103被添加到了脚本任务的ReadWriteVariables列表中，SSIS 2016会确保脚本中对该变量有合法的引用/赋值操作，未正确赋值可能触发错误。
  2. 新版本的编译引擎可能对变量的重复赋值逻辑更敏感，或者你的包在2016中启用了更严格的验证选项，导致原本在2012中被忽略的逻辑错误暴露出来。

解决方法很直接：把最后一行代码修正为Variables.ContainerDisable103 = C103;，同时检查脚本任务的变量引用配置，确保ContainerDisable103被正确添加到变量列表中。

内容的提问来源于stack exchange，提问作者John McElreavey