Is it possible to use relative paths for SSIS packages dtsConfig files?

Question

I am trying to make our SQL Server Integration Services packages as portable as possible and the one thing that is preventing that is that the path to the config is always an absolute path, which makes testing and deployment a headache. Are there any suggestions for making this more manageble?

Another issue is when another developer gets the package out of source control the path is specific to the developers machine.

Answer 1

If you are trying to execute your packages using Visual Studio then the configuration file path will be hardcoded in there. So if you move your project around you'll need to change the path in the package settings. To avoid this you could use the Environment variable option to store the configuration file path. Then you'll only need to change that.

For testing and deployment however you should probably use the dtexec utility to execute your packages. Make some batch files for that. Preferably one for each different environment. Here the configuration file path can be relative.

dtexec /File Package.dtsx /Conf configuration.dtsConfig"

This is if you're packages are on file system. You can also store them in SQL Server. You can also store your configuration in SQL Server which may provide flexibility.

Answer 2

After several hours trying to make this work I found a solution here (not the best one, but it works)

1. Locate your configuration files (dtsconfig files) in the same directory as your solution file (.sln file)
2. ALWAYS open your solution by double-clicking the solution file (.sln file). This will set the ‘working folder’ to be where the solution lives, your configuration file will be read correctly

Otherwise the relative paths did not work for me.

Answer 3

Check out the free utility that can edit SSIS configuration file paths without BIDS: http://ssisconfigeditor.codeplex.com/

Answer 4

My stock standard trick for these sorts of problems are mapping drives.

Either by using a mapped network drive or by using Subst (both methods are interchangable).

e.g. Map the location of your package to N:\ then inside your package use paths using N:\MyParentPackage.dtsx, N:\MyChildPackage.dtsx. The packages can be on totally different drives in different folders on different machines, it'll work once you map the package location to the N:\

I usually put a script along side the project files to map the drive, which maps the drive so it can be easily run before. One gotcha, if you're using subst on VISTA - Win8, map it for elevated and non-elevated.

I use the same approach for file references in Visual Studio projects. Only issue with this approach, you use to solve too many issues in your dev environment and you'll run out of drives letters.