Does ConfigurationPropertyCollection need to be static?

Question

According to this oft-referenced article, Unraveling the Mysteries of .NET Configuration , when implementing a ConfigurationSection / ConfigurationElement, it is recommended to follow this pattern:

private static ConfigurationPropertyCollection s_properties;
static ExampleSection()
{
        // Predefine properties here
        // Add the properties to s_properties
}

/// Override the Properties collection and return our custom one.
protected override ConfigurationPropertyCollection Properties
{
    get { return s_properties; }
}

But it does not explain why the s_properties field would need to be static, and the properties initialized in a static constructor.
After all, it's only accessed via the non-static Properties overridden property...

(I have a complicated set of custom configuration management, it would greatly simplify things having the s_properties field be NOT static...)

So, is there some "hidden" access directly to the static field? Is the Configuration*** object continually created and re-created, such that object-level fields would be lost, and as such is inefficient?
Or is it perfectly fine to store and initialize the ConfigurationPropertyCollection as non-static?

Answer 1

But it does not explain why the s_properties field would need to be static,

The reason s_properties is static is because you the developer only wanted one set - a singleton instance - of configuration properties for an application. [ And this may be considered typical .] The ConfigurationXXX (ConfigurationManager, for example) classes are static because you should only require one per AppDomain.

Basically, in the sample:

private static ConfigurationPropertyCollection s_properties;
static ExampleSection()
{
        // Predefine properties here
        // Add the properties to s_properties
}

/// Override the Properties collection and return our custom one.
protected override ConfigurationPropertyCollection Properties
{
    get { return s_properties; }
}

the author is assuming you should only have a single instance of s_properties .

So, is there some "hidden" access directly to the static field?

Not sure I follow this question.

Is the Configuration*** object continually created and re-created, such that object-level fields would be lost, and as such is inefficient?

[Edit: Depends... I was considering the ConfigurationManager. But, say I wanted to have a local copy of my AppSettingsCollection. I would make that a static readonly field declaration. In the context of Sections, etc. Then I would still use a static field inializer, albeit a static Dictionary<string, ConfigurationPropertyCollection> Properties . In the end, I still believe that you would only ever want a single instance of your property settings collection. ]

[Original with other [ edits ] ]
No. [ Static ] ConfigurationXXX objects are not continually created, disposed, and re-created. Like all static objects, a public static initializer/constructor is executed a single time - the first time that object is called. For instance, when I call the following:

string someValue = ConfigurationManager.AppSettings["SomeKey"];  

The static ConfigurationManager class constructor is executed. Since this class is static, it will live for the lifetime of the current AppDomain in which it is executed.

I would not recommend initializing app domain properties, configuration properties, or property collections as or within an instance class. When your program begins execution, you should rely on a static Configuration class in which you wrap and customize interaction with ConfigurationXXX classes, members, and functions.