DEV Community

Cover image for Bundling NuGet Package Dependencies in an SSIS Script Task
Oleksandr Shevchenko
Oleksandr Shevchenko

Posted on

Bundling NuGet Package Dependencies in an SSIS Script Task

#nuget #dotnet #etl #ssis

Bundling NuGet Package Dependencies in an SSIS Script Task

If you've ever tried to reference a NuGet package with its own dependency tree from inside an SSIS Script Task, you've probably hit the same wall: it works fine in Visual Studio, then falls over the moment the package runs from the command line on a server. This walkthrough shows how to fix that properly — referencing any NuGet package with dependencies in a Script Task and bundling those dependencies so the package runs correctly outside of Visual Studio, without relying on the embedded DLLs option. A private package, Contoso.SampleLibrary, is used throughout as a concrete example.

Problem: SSIS Script Tasks that reference NuGet packages fail to execute from the CLI.

Solution: Temporarily point NuGet at the solution's packages folder, then use Costura.Fody to embed the required assemblies directly into the package.

Prerequisites

  • Visual Studio with the SSIS project open.
  • Access to your organization's private NuGet package source.

Step 1: Temporarily update NuGet.Config

Open %AppData%\NuGet\NuGet.Config — the user-level NuGet configuration file — and temporarily add a repositoryPath that points to the solution's packages folder.

Note: repositoryPath is resolved relative to the location of NuGet.Config, not the solution directory, so it must be specified as an absolute path.

Info: This update only redirects where packages are downloaded during script edit mode — from a temporary folder to a constant, persistent one. NuGet automatically resolves and chooses the proper compatible version of each library to incorporate into the solution.

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <config>
    <add key="repositoryPath" value="C:\path\to\solution\packages" />
  </config>
  <packageSources>
    <add key="YourOrg.PrivateFeed"
         value="https://pkgs.dev.azure.com/your-org/_packaging/YourOrg.PrivateFeed/nuget/v3/index.json"
         protocolVersion="3" />
  </packageSources>
</configuration>
Enter fullscreen mode Exit fullscreen mode

Replace C:\path\to\solution\packages with the actual path to the solution's packages folder.

Step 2: Install the required packages

In Visual Studio:

  1. Right-click the Script Task project and select Manage NuGet Packages.
  2. Choose your organization's private package source.
  3. Search for and install Contoso.SampleLibrary.
  4. Also install Costura.Fody.

Info: Installing a package also pulls in its transitive dependencies automatically — see the summary below for how many packages this involves in this example.

Info: Costura.Fody embeds all third-party libraries directly inside the .dtsx file as binary resources, eliminating the need for an AssemblyResolver or any additional custom classes within the Script Task project.

Because the DLLs are embedded as binary data in the .dtsx file, the packages folder is only needed while editing the script in Visual Studio (script edit mode). On production/runtime servers, the packages folder is not required — everything needed is already embedded in the package.

After installation, restart the Script Task project so it picks up the new DLLs from NuGet.

Step 3: Clean up the temporary configuration

Once the installation is complete, remove the temporary package source and repositoryPath entries from:

%AppData%\NuGet\NuGet.Config
Enter fullscreen mode Exit fullscreen mode

⚠️ Warning: These entries are only required for the one-time package restore and should not remain in the global NuGet configuration.

Summary

In this example, NuGet downloads 19 packages (dependencies) together with Contoso.SampleLibrary. No one would want to manually include all of them in an SSIS solution, especially since many of these packages contain multiple subfolders for different target runtimes and frameworks.

Even if a manual approach were used, maintaining and updating all of these libraries in the future would become another challenge. By using a combination of NuGet.Config and Costura.Fody, the SSIS solution can behave more like a traditional .NET application. This approach simplifies dependency management, automatically resolves compatible package versions and runtimes, and bundles the required assemblies, resulting in a more consistent and maintainable deployment model.

Have you run into NuGet dependency headaches in SSIS Script Tasks, or found a different approach that works for you? Let me know in the comments.

Top comments (0)