.NET 2.0 Configuration (attempt 2)

[Michael Lang]

I was basically wanting to know how to use the System.Configuration
namespace to be able to load an arbitrary number of unknown attributes on an
element in a custom section in the .config into a NameValueCollection.

Basically I want to do something similiar to what occurs with a
System.Configuration.Provider.ProviderBase Initialise method - the provider
is passed a NameValueCollection containing attribute names and their
associated values from the .config. see...

http://msdn2.microsoft.com/en-us/library/system.configuration.provider.providerbase.initialize.aspx

All the examples I've seen with the .NET 2.0 config api deal with scenarios
where the attributes are predefined and loaded using static code.

One brute force solution that comes to mind is just to by-pass the
Configuration api and use XML/DOM to parse the web config . But if there's
a more elegant solution that leverages the .NET Config API I'd like to use
it.

I've already asked this question once, I had one response which in summary
suggested I should use the System.Configuration Namespace.... not exactly
helpful.

Thanks in advance

Michael

 

[Kevin Spencer]

ProviderBase is an abstract class, meaning that it is not used; only derived
classes are used. A Configuration Section is serialized class data. As such,
the class which reads/deserializes the Configuration Section must know what
to expect in the attributes. In this case, the class must know the names,
types, and acceptable values of each Name/Value in the collection. It is
because ProviderBase is abstract that it does not define what attributes
there should be, what types they are, or what the acceptable values are.

..Net Framework 2.0 Configuration is strongly-typed, and for good reasons,
beyond the scope of this answer. For a more accurate idea of an
implementation of ProviderBase, see the documentation for the
SqlMembershipProvider class, which is derived from ProviderBase:

http://msdn2.microsoft.com/en-us/library/system.web.security.sqlmembershipprovider.aspx

As you will see, it is strongly-typed, and knows exactly what attributes it
is looking for.

--
HTH,

Kevin Spencer
Microsoft MVP
Software Composer
http://unclechutney.blogspot.com

The shortest distance between 2 points is a curve.

 

[Guest]

Hi Michael,

I do not think it is possible to use unknown attributes because you have to
derive from ConfigurationElement and provide information about the expected
attributes. But maybe the following example may be an option for you?

<configuration>
<configSections>
<section name="testaddins"
type="WindowsApplication1.AddinConfigurationSection,WindowsApplication1" />
</configSections>

<testaddins>
<addins>
<addin path="1">
<addinproperties>
<property name="test1" value="a" />
<property name="test2" value="b" />
</addinproperties>
</addin>
<addin path="2">
<addinproperties>
<property name="test3" value="c" />
<property name="test4" value="d" />
</addinproperties>
</addin>
</addins>
</testaddins>
</configuration>

In this example I have used subelements (<property>) to describe arbitrary
data for each addin instead of attributes as you suggested. If this might
solve your problem please let med know and I would be glad to provide you
code to read this configuration section.

HTH, Jakob.

 

[Michael Lang]

I had thought my solution might be to derive my configured class from
ProviderBase.

My class is also an abstract class, and it is designed to be inherited and
allow deriving classes to configure themselves by adding attributes to the
config. However I was wanting to use this class for both ASP.NET and other
project types.

Whilst ProviderBase resides in the System.Configuration.Provider namespace
it talks about ASP.NET. Plus I haven't seen any examples of how you go
about using the ProviderBase without the
System.Web.Configuratoin.ProviderHelper.

This seems like a bit of a mess to me. In my mind there is no way you
should have things in System.Configuration.Provider having dependencies on
things in System.Web.Configuration.

Do you know of sample code that uses ProviderBase for a custom configuration
for something other than ASP.NET ?

 

[Michael Lang]

OK for anyone out there I can spare some pain, I've worked a solution out.

---------------------------------------------------------------------------------------------------------
// CustomSection...

public class CustomConfig : ConfigurationSection
{
/// <summary>
/// Provider section configuration
/// </summary>
public const string ProviderName = "Provider";

/// <summary>
/// Gets the configuration settings for the <see
cref="YourCustomProvider"/>
/// </summary>
[ConfigurationProperty(ProviderName, IsRequired = true)]
public ProviderSettings ProviderConfig
{
get
{
return (ProviderSettings)this[ProviderName];
}
}
}

// Config...

<mysection>
<subsection>
<Provider name="YourTestProvider"
type="YourAssembly.UnitTests.TestProvider, YourNamespace.YourCustomProvider,
Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
</subsection>
</mysection>

/* Most examples out there deal with a collection of providers. For my
needs I only need a single provider, so if you need a collection you can
adapt this code by substituting ProviderSettings with
ProviderSettingsCollection, then you'll need to loop through this collection
of ProviderSettings applying the code below to each member of the
collection.

I think an example for configuring single provider is probably quite useful
to any people out there who don't need or want a collection of providers for
there architecture...

The following code is basically a substitute for the
System.Web.Configuration.ProvidersHelper.
*/

YourCustomProvider providerInstance;
CustomConfig retConfig =
(CustomConfig)System.Configuration.ConfigurationManager.GetSection("mysection/subsection");
if (retConfig != null && retConfig.ProviderConfig != null)
{
ProviderSettings providerSettings = retConfig.ProviderConfig;
Type providerType = Type.GetType(providerSettings.Type);
providerInstance = Activator.CreateInstance(providerType) as
YourCustomProvider;
providerInstance.Initialize(providerSettings.Name,
providerSettings.Parameters);
}

---------------------------------------------------------------------------------------------------------

In my view the whole ProviderBase thing is dire need of refactoring.
ProvidersHelper shouldn't be in System.Web.Configuration. You could also
argue that all the ProviderSettings and ProviderSettingsCollection in
System.Configuration should be in the System.Configuration.Provider
namespace.

Maybe I'm getting lazy but I think the Provider related stuff is spread
across too many namespaces, making it unnecessarily confusing.

Michael