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.ConfigurationMa nager.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
"Michael Lang" <micklang at gmail.comwrote in message
news:OY**************@TK2MSFTNGP02.phx.gbl...
>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 ?
"Kevin Spencer" <un**********@nothinks.comwrote in message
news:%2****************@TK2MSFTNGP05.phx.gbl...
>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/lib...pprovider.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.
"Michael Lang" <micklang at gmail.comwrote in message
news:uu**************@TK2MSFTNGP05.phx.gbl...
>>>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/lib...nitialize.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
