My parent package calls packages stored in the file system. While developing, I would like to call packages in the project bin directory. In production, I would like to call packages in a different development. Is this possible? I can change the package connection string with an expression that refers to user variables PackageLocation1 or PackageLocation2. I would like to do this automatically. Is this something that should be done at deployment time? Or isthere arun time value that I can check and conditionally use PackageLocation1 or PackageLocation2? Development and deployment is done on the same server, so the same enivronment variable value would be used in an indirect configuration. Same thing applies to a file configuration. Another question: Is it possible to set up a different Installation Folder for use during deployment? Every time I deploy, I have to navigate the folders, you can't even paste in the folder name.

As far as I know there is no easy to use relative paths feature in SSIS. I'm currently putting all my SSIS packages(and projects) in folders under "C:\SSISPackages\". There is a whole tree structure under this folder.Each SSIS project has a separate folder under this root path. My XML configuration files are located in "C:\SSISPackages\Configs" so that all the packages can access the same configs to get their database connection settings. As long I set up myDevelopment,QA andProduction machines with thisexact same folder structure everything works great. However, this is probably not the best possible solution. In the future Imight modify the packages to read the root folder path ("C:\SSISPackages\") from a registry key. This would allow the files to be moved but, it's a lot of work for a very small feature that users will never see, much less appreciate. Later, Greg Van Mullem

Greg Van Mullem wrote: As far as I know there is no easy to use relative paths feature in SSIS. I'm currently putting all my SSIS packages(and projects) in folders under "C:\SSISPackages\". There is a whole tree structure under this folder.Each SSIS project has a separate folder under this root path. My XML configuration files are located in "C:\SSISPackages\Configs" so that all the packages can access the same configs to get their database connection settings. As long I set up myDevelopment,QA andProduction machines with thisexact same folder structure everything works great. However, this is probably not the best possible solution. In the future Imight modify the packages to read the root folder path ("C:\SSISPackages\") from a registry key. This would allow the files to be moved but, it's a lot of work for a very small feature that users will never see, much less appreciate. Later, Greg Van Mullem greg, Users may never see it but then they never see anythig in SSIS. They will sure appreciate it when you can churn out new functionality quickly. Storing a rootfolder in somewhere like a registry key is a fantastic idea and its an approach that I preach about constantly. It helps to make your packages location independent. -Jamie

Jamie,I have always wondered how other people handled this. We only have 2 programmers on staff at my company so we have to be very diligent in where we spend our time. It's a lot of work building and maintainingan entire application architecture with just 2 programmers. Needless to say, we have to cut a few strategic corners every once and a while.Later,Greg Van Mullem

There is now an open source utility available in CodePlex which can be used to batch update SSIS Package Configuration File paths without using BIDS or manually editing the package XML: http://ssisconfigeditor.codeplex.com/