Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
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.
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.
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.