Safety Of Using .NET Static Members As Configuration Transport.

Situation:
We have a backend system which stores our configuration data. In order to pull configuration information from this system our components need to have access to three pieces of data: application name, module name, and the variable to pull.

This same system allows us to log various events. It serves as a central point of configuration, maintenance and monitoring for all of our environments.

Desired Outcome:
We'd like to create a connection manager, log provider, and task "finalizer." We'd like to initialize the variables named above in one location and have all created components pull their required information from that one location.

Assumptions:
* Custom configuration managers are not possible.
* Custom connection managers and logging providers do not have access to the package variables.
* Custom tasks have access to the package variables.


Problems:
Logging Provider: The logging provider does not have access to the package level variables. The only variable that appears to be supported is ConfigString. Currently our component allows configuration of the required data using a "Variable::Variable" format in the ConfigString. We want the logging provider to pull its config data from elsewhere.

Connection Manager: The connection manager does not appear to have access to package level variables. The UI for configuring the connection manager does have access (through the IDtsVariableService). Our current component requires the designer to enter the required data into the component.

We're looking to expand our components to include further integration into our backend. We'd like to resolve the issue of components not having access to the package level variables.


Probed Solutions:
Custom Package Executable: Created as a replacement for DTExec. This fails because we have situations where we may need to run jobs via SQLAgent. Loaded the package, set all the variables and components properly, then executed.

Manual Initialization: Configure each component separately. This fails because we'd like to have a single point of maintenance for these configuration variables.


DTSTask and Static Variables: The heart of this post.

We have created a DTSTask that exists as the first item in the Control Flow and which configures the package level variables and a set of static variables. By "static variables" I refer to the following:


public static class DataStore
{

public static string ApplicationName;
public static string ModuleName;
}

Our components are all capable of accessing these static variables and everything functions wonderfully. (The variables are WORM; the above structure is not what I'm using as I'm aware that SSIS is multi threaded and all appropriate access controls should be used.)

There are concerns over the lifetime of these variables. We depend on the initial task to set these variables; a type constructor is unable to initialize them for us. Static variables are tightly tied to the lifetime of the AppDomain, so I have the following questions:

1. Are AppDomains reused by SSIS? (Is there a chance that a previously configured static variable will be used by a second package?) Research I've done indicates that the SSIS runtime exists in the context of the executing assembly so with DTExec or DTExecUI I'm confident that the AppDomain is not recycled; however, I'm unsure as to the answer in terms of jobs launched by SQLAgent.
2. Are AppDomains ever dynamically created by the SSIS runtime? I know that dynamic creation of AppDomains is explicitly forbidden by the SQL Server 2005 CLR implementation, but I'm not sure about the SSIS runtime. Research has seemed to indicate (but never explicitly state) that this is not done by the current implementation of SSIS.

3. What effect, if any, does "execute out of context" have on static variables? Research has indicated that as long as the package being executed has the appropriate task as the first item that the impact is nil.

Thank you for reading this question, and thank you in advance for any input or comments you may have.
--bms