Introduction

Executing an SSIS package from .NET can mean two different things: launching a package file directly through the SSIS runtime APIs, or invoking an already deployed package through tooling such as dtexec or the SSIS catalog. The best approach depends on where the package lives and how much control your application needs over logging, parameters, and deployment environment.

Running a Package with the SSIS Runtime API

If you have the package file and the required SSIS runtime installed, you can load and execute it directly from .NET.

1using Microsoft.SqlServer.Dts.Runtime;
2
3class Program
4{
5    static void Main()
6    {
7        var app = new Application();
8        Package package = app.LoadPackage(@"C:\ETL\ImportCustomers.dtsx", null);
9
10        DTSExecResult result = package.Execute();
11        Console.WriteLine(result);
12    }
13}

This approach gives you direct access to package variables, events, and result status inside the application process.

Calling dtexec from .NET

Sometimes the simpler operational choice is to let SQL Server’s command-line tooling run the package.

1using System.Diagnostics;
2
3var process = new Process();
4process.StartInfo.FileName = "dtexec";
5process.StartInfo.Arguments = "/FILE "C:\ETL\ImportCustomers.dtsx"";
6process.StartInfo.RedirectStandardOutput = true;
7process.StartInfo.RedirectStandardError = true;
8process.StartInfo.UseShellExecute = false;
9
10process.Start();
11string output = process.StandardOutput.ReadToEnd();
12string error = process.StandardError.ReadToEnd();
13process.WaitForExit();

This is less integrated than the runtime API, but it can align better with environments that already treat SSIS as an external execution platform.

Choose Based on Deployment Style

A useful rule is:

• use the runtime API when your application needs in-process control,
• use dtexec or catalog execution when SSIS is operationally managed outside the application.

That distinction matters because package execution is not only a coding question. It is also a deployment and ownership question.

Handle Parameters, Logging, and Failures Deliberately

Whichever route you choose, production use usually needs:

• parameter injection or configuration handling,
• detailed logging of package messages,
• success and failure reporting,
• timeout or retry policy if the package runs as part of a larger workflow.

A minimal example that only prints a success flag is fine for demonstration, but real ETL orchestration usually needs more observability than that.

Watch for Environment Dependencies

SSIS execution depends heavily on the environment: installed runtime version, package dependencies, SQL Server connectivity, file paths, and permissions. Many "execution from .NET" failures are really deployment mismatches rather than coding problems.

That is why testing on the real host environment matters more than only verifying the code compiles.

Catalog-Based Execution Is Another Operational Pattern

In teams that deploy packages to SSISDB, the application may trigger an already deployed package rather than loading a .dtsx file directly. That keeps package storage, versioning, and execution management inside the SQL Server environment and can be easier to operate than shipping package files alongside the application.

Common Pitfalls

• Choosing the runtime API when operational tooling should own package execution instead.
• Launching dtexec without capturing its output and error streams.
• Ignoring runtime and deployment dependencies such as installed SSIS components or permissions.
• Treating package success as binary when detailed logging is needed for ETL troubleshooting.
• Coupling application logic too tightly to environment-specific SSIS file paths.

Summary

• You can execute SSIS packages from .NET either directly through the runtime API or indirectly through tooling such as dtexec.
• The right choice depends on deployment ownership and how much in-process control you need.
• Runtime access is powerful, but command-line execution can be operationally simpler.
• Logging and failure handling matter as much as the execution call itself.
• Many problems blamed on code are actually environment and runtime configuration issues.