Package.dtsx -> XML format description/manual request

Hi All,

As I see it is possible to view a package (dtsx) in XML form.

Is the XML stable and documented? Would it be good decision to

use the XML as source for third party development or we need to use

some API to get package's content ? Where I could get the package's XML

structure description/manual ?

Thanks,

Sergiy

I'd say the overall schema is stable, but it is not publically documented so subject to change I guess. What will change is the detailed sections within tasks or components that describe properties. Task or component developers can change that whenever they feel like, and may do. Whilst that may sound a bit dangerous, it is perfectly acceptable since they would be expected to write the appropriate code to upgrade between component versions, or even downgrade gracefully if required, it is possible.

The safest way would be to use the API/object model, but XML may be sufficient for what you need. Just think what will happen if a new element or attribute appears because a new version of a task comes out and it has a new property. Examples of this are some of my own developed tasks, or changes MS made in SP1.

Package with File System Task doesn't work without sensitive data with user keys

This problem is a bit weird but I'm just wondering if anybody else experienced this.

I have a package that has file system tasks (copying dtsx files actually). Basically the package copies other packages to a pre-defined destination. Thing is, it only works if one of the packages it is configured to copy has some sort of sensitive data (e.g., a connectionstring with a password), otherwise it reports a success message on execution but doesn't actually do anything. I've checked the forcedexecutionresult and it is set to None for that matter.

Just wondering if anybody else experienced this problem and of course if there's a way to solve it.

Thanks.Could the security permissions be different on your packages that are failing to be moved from those that are succeeding?|||No, they're all set to EncryptSensitiveWithUserKey.

However, all of the packages involved have their sensitive information set to obtaining them from Indirect Configuration Files. The only way around that I found so far was to put in a dummy connection object, set up an XML file package configuration for that dummy, and deploy it that way.

I'm suspecting that the user key isn't generated at all when all the packages get their configs from Indirect Configuration Files. For some reason, DontSaveSensitive doesn't work either. My original package insists on the presence of a key. Might have something to do with file read/write/modify permissions that come with the key?

I still want to do away with the dummy though.