Hi,

I've noticed that SSIS saves paths to configuration files as absolute paths.
It does do that with the Execute Package task as well.

This way it's very hard to move a SSIS project to another location. I wonder
now I can easily deploy an SSIS project to a production server, where the
SSIS package will definitively be stored somewhere else than on my local
development machine. But more than that I wonder how I will be able to
transport an SSIS project between development workstations having different
configuration.

How can I have Visual Studio/SSIS use a relative file path when storing
configuration files in a dtsx file? Same for File Manager used by the
Execute Package task?

TIA,
Axel Dahmen

Hi Axel,

Take a look into Indirect Configuration (search on the MSDN website).
It requires using an Environment Variable, but this is generally
accepted as the best way of managing configurations. I would also
recommend storing your configurations in a table rather than in
files. It's generally just easier to manage, and deployment can get
messy if you try to deploy multiple packages that use the same config
file using the deployment utility (well .. the deployment utility is
just generally flaky in my experience. I last used it on the CTP
though, so maybe it's improved since then )

Good luck!
J

Hi Axel,

Take a look into Indirect Configuration (search on the MSDN website).
It requires using an Environment Variable, but this is generally
accepted as the best way of managing configurations. I would also
recommend storing your configurations in a table rather than in
files. It's generally just easier to manage, and deployment can get
messy if you try to deploy multiple packages that use the same config
file using the deployment utility (well .. the deployment utility is
just generally flaky in my experience. I last used it on the CTP
though, so maybe it's improved since then )

Good luck!
J

Hi Axel,

Take a look into Indirect Configuration (search on the MSDN website).
It requires using an Environment Variable, but this is generally
accepted as the best way of managing configurations. I would also
recommend storing your configurations in a table rather than in
files. It's generally just easier to manage, and deployment can get
messy if you try to deploy multiple packages that use the same config
file using the deployment utility (well .. the deployment utility is
just generally flaky in my experience. I last used it on the CTP
though, so maybe it's improved since then )

Good luck!
J

Hi Axel,

Take a look into Indirect Configuration (search on the MSDN website).
It requires using an Environment Variable, but this is generally
accepted as the best way of managing configurations. I would also
recommend storing your configurations in a table rather than in
files. It's generally just easier to manage, and deployment can get
messy if you try to deploy multiple packages that use the same config
file using the deployment utility (well .. the deployment utility is
just generally flaky in my experience. I last used it on the CTP
though, so maybe it's improved since then )

Good luck!
J

Hi Axel,

Take a look into Indirect Configuration (search on the MSDN website).
It requires using an Environment Variable, but this is generally
accepted as the best way of managing configurations. I would also
recommend storing your configurations in a table rather than in
files. It's generally just easier to manage, and deployment can get
messy if you try to deploy multiple packages that use the same config
file using the deployment utility (well .. the deployment utility is
just generally flaky in my experience. I last used it on the CTP
though, so maybe it's improved since then )

Good luck!
J

Hi Axel,

Take a look into Indirect Configuration (search on the MSDN website).
It requires using an Environment Variable, but this is generally
accepted as the best way of managing configurations. I would also
recommend storing your configurations in a table rather than in
files. It's generally just easier to manage, and deployment can get
messy if you try to deploy multiple packages that use the same config
file using the deployment utility (well .. the deployment utility is
just generally flaky in my experience. I last used it on the CTP
though, so maybe it's improved since then )

Good luck!
J

Hi Axel,

Take a look into Indirect Configuration (search on the MSDN website).
It requires using an Environment Variable, but this is generally
accepted as the best way of managing configurations. I would also
recommend storing your configurations in a table rather than in
files. It's generally just easier to manage, and deployment can get
messy if you try to deploy multiple packages that use the same config
file using the deployment utility (well .. the deployment utility is
just generally flaky in my experience. I last used it on the CTP
though, so maybe it's improved since then )

Good luck!
J

Hi Axel,

Take a look into Indirect Configuration (search on the MSDN website).
It requires using an Environment Variable, but this is generally
accepted as the best way of managing configurations. I would also
recommend storing your configurations in a table rather than in
files. It's generally just easier to manage, and deployment can get
messy if you try to deploy multiple packages that use the same config
file using the deployment utility (well .. the deployment utility is
just generally flaky in my experience. I last used it on the CTP
though, so maybe it's improved since then )

Good luck!
J

Hi J,

thanks for your reply. Unfortunately it's not only configuration that's saved using absolute paths. It's also e. g. packages addressed by the Execute Package task.

It's very hard to work with a project on different machines. I can't (and don't want to) have a single development path on those machines, one at my laptop and the other at my customers'.

TIA,
Axel Dahmen


----------------------------------------
<jhofmeyr (AT) googlemail (DOT) com> schrieb im Newsbeitrag news:6708cd67-2110-42e7-8630-f0fdda87a823 (AT) r66g2000hsg (DOT) googlegroups.com...