.NET调用SQL Server 2012 SSIS包时Execute SQL Task未执行问题

我之前遇到过类似的情况，从SQL Server 2005升级到2012后，SSIS包在工具里正常运行但.NET调用时部分任务失效，大概率是版本兼容或配置差异导致的，给你几个排查方向：

1. 检查SSIS运行时组件版本 #

SQL Server 2005和2012的SSIS运行时组件是完全不同的版本（2005是9.0.x，2012是11.0.x）。你的.NET程序如果还在引用旧版本的Microsoft.SqlServer.Dts.Runtime等DLL，就会导致包执行时行为异常：

• 打开你的.NET项目，检查引用的SSIS相关组件版本，确保全部替换为SQL Server 2012对应的版本（版本号11.0.0.0）。
• 如果找不到对应版本，需要安装SQL Server 2012的Integration Services客户端工具，或者从SQL Server安装目录（默认C:\Program Files\Microsoft SQL Server\110\SDK\Assemblies）手动添加引用。
• 可以在app.config里添加绑定重定向，避免版本冲突：

  <dependentAssembly>
    <assemblyIdentity name="Microsoft.SqlServer.Dts.Runtime" publicKeyToken="89845dcd8080cc91" culture="neutral" />
    <bindingRedirect oldVersion="9.0.0.0" newVersion="11.0.0.0" />
  </dependentAssembly>
  

2. 验证SSIS包的保护级别设置 #

SQL Server 2012对SSIS包的敏感数据加密机制有更严格的要求，这是最常见的坑：

• 如果你的包设置了EncryptSensitiveWithUserKey，那么只有创建包的用户或相同Windows用户才能解密敏感数据（比如连接字符串）。当.NET程序用不同用户身份运行时，Execute SQL Task可能因为无法获取有效连接而静默失败。
• 解决方法：
  • 把包的保护级别改成EncryptSensitiveWithPassword，然后在.NET代码里设置包的密码：

    pkg.Password = "YourPackagePassword";
    

  • 或者改为DontSaveSensitive，同时在代码里显式设置连接管理器的连接字符串：

    foreach (ConnectionManager cm in pkg.Connections)
    {
        if (cm.Name == "YourSourceConnection")
        {
            cm.ConnectionString = "Data Source=YourServer;Initial Catalog=YourDB;Integrated Security=SSPI;";
        }
    }
    

3. 捕获包执行的详细日志和任务状态 #

你说程序返回执行成功，但可能Execute SQL Task实际是被跳过或执行失败却没抛出异常。添加代码捕获每个任务的执行状态：

using Microsoft.SqlServer.Dts.Runtime;

DtsApplication app = new DtsApplication();
// 如果需要32位运行时，添加下面一行
// app.Use32BitRuntime = true;
Package pkg = app.LoadPackage(@"C:\YourPackage.dtsx", null);
DTSExecResult result = pkg.Execute();

// 遍历所有任务，输出执行状态
foreach (Executable exec in pkg.Executables)
{
    if (exec is TaskHost taskHost)
    {
        Console.WriteLine($"任务名称: {taskHost.Name}");
        Console.WriteLine($"执行状态: {taskHost.ExecutionStatus}");
        Console.WriteLine($"执行结果: {taskHost.ExecuteResult}\n");
    }
}

通过这些日志，你能明确看到Execute SQL Task是未启动、被跳过还是执行失败，从而定位具体原因。

4. 检查32位/64位兼容性 #

Execute Package Utility（dtexecui.exe）默认是32位程序（如果从SSMS启动，SSMS本身也是32位），而你的.NET程序可能是64位的，这会导致部分组件不兼容：

• 在.NET项目的属性里，把目标平台改成x86，强制以32位模式运行。
• 或者在代码里设置app.Use32BitRuntime = true，让SSIS包以32位运行时执行，和Execute Package Utility保持一致。

5. 验证Execute SQL Task的延迟验证设置 #

如果你的Execute SQL Task启用了延迟验证，在2012版本中可能因为连接初始化时机的变化，导致任务无法正确触发。可以尝试关闭该任务的延迟验证选项，再重新测试。

按照上面的步骤逐一排查，应该能找到问题所在。

内容的提问来源于stack exchange，提问作者Jeff Nichols