Day 3 – Package Level Properties


Today will we display the package properties and make the first modification to the package. At the end, we will save the which can be useful when debugging later steps.




Package properties are the top level of the tree. They describe the overall package as well as how it behaves during execution. All tasks will inherit some or all of the package level properties. Most scheduling utilities we record all statements sent to the console (screen) during execution, so this information will be available in the logs of the scheduler. The code is very simple:


//list the package properties






Name stores the descriptive name of the package, not the file name and can be used to describe the package in more detail.

CreationDate is the date stamp of when you created you package file. It does not update when you save the file.

ID is a GUID that is randomly generated and should be unique to each package that you create.

VersionBuild starts at one and incremented each time you save the file in BIDS.


These properties are very important for sorting out two or more packages with the same file name. I record both ID and VersionBuild each time that I move a new or updated package to the server and can use these to determine if the package has been tampered. It is not 100% full proof as we have already discussed how to manually edit the package, but in most circumstances it is enough information to determine if changes were made.



Enable Logging

Prior to this framework, it was the responsibility of the development team to enable logging. Typically, it was an afterthought and was not implemented until an error occurred in production. We will enable logging at the package level, but each task will need to be configured as well.

pkg.LoggingMode = DTSLoggingMode.Enabled;



All of the changes that we make to the package will only be in memory. None of them will be wrote to disk and will be lost when the executable completes. It may seem odd to set properties on each execution when they could be done once and stored for future execution. However, this would prevent the ability to modify settings in the framework that could affect all packages, such as the path for the log file. If we kept the updated version, we would need a process to determine which packages would need to be updated and saved each time we made a configuration change.

In the early phases of adoption, I saved a copy of the package to disk prior to each execution. This enabled the team to view the properties of the package after all changes were made to ensure that all steps were working as desired. For today, we will save it to the original location.

app.SaveToXml(PackagePath, pkg, null);



Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s