G
Guest
I'm probably missing something because the .NET configuration model seems
pretty screwed up. Since the configuration file is an XML file it would seem
to make sense, at least to me, to have the reading/writing of configuration
information rely on the XmlSerializer. Instead they came up with a whole new
set of configuration attributes to do, I guess, the same (or similar) thing
the XmlSerialization attributes do. Why?
Getting to my question at hand, I plan to use the XmlSerializer to read data
from my application configuration file. I would like to be able to request a
section and get back an XmlNode for that section. I will then deserialize
that using the XmlSerializer. I was hoping that I could simply call
ConfigurationManager.GetSection(...) passing in my section name and get back
an XmlNode. However, that doesn't work. So after looking at all the derived
ConfigurationSection classes it appears as if the DefaultSection class will
allow me to get an XML string which represents the section. Is this true? I
was hoping to get an XmlNode because I was thinking that the framework had it
in that form and didn't want to have to serialize back to a string.
I was also surprised that there doesn't seem to be any way to
programmatically specify a configSection. I seems as if I'm stuck having to
do the following:
<configuration>
<configSections>
<section name="orderFill" type="System.Configuration.DefaultSection,
System.Configuration, Version=2.0.0.0, Culture=neutral,
PublicKeyToken=b03f5f7f11d50a3a"/>
</configSections>
....
</configuration>
It's kind of ugly and if I know in the code that I want to use the
DefaultSection why can't I somehow tell the framework at runtime that I want
to add a new configSection removing the need to specify it in the application
configuration file?
--
Thanks,
Nick
(e-mail address removed)
remove "nospam" change community. to msn.com
pretty screwed up. Since the configuration file is an XML file it would seem
to make sense, at least to me, to have the reading/writing of configuration
information rely on the XmlSerializer. Instead they came up with a whole new
set of configuration attributes to do, I guess, the same (or similar) thing
the XmlSerialization attributes do. Why?
Getting to my question at hand, I plan to use the XmlSerializer to read data
from my application configuration file. I would like to be able to request a
section and get back an XmlNode for that section. I will then deserialize
that using the XmlSerializer. I was hoping that I could simply call
ConfigurationManager.GetSection(...) passing in my section name and get back
an XmlNode. However, that doesn't work. So after looking at all the derived
ConfigurationSection classes it appears as if the DefaultSection class will
allow me to get an XML string which represents the section. Is this true? I
was hoping to get an XmlNode because I was thinking that the framework had it
in that form and didn't want to have to serialize back to a string.
I was also surprised that there doesn't seem to be any way to
programmatically specify a configSection. I seems as if I'm stuck having to
do the following:
<configuration>
<configSections>
<section name="orderFill" type="System.Configuration.DefaultSection,
System.Configuration, Version=2.0.0.0, Culture=neutral,
PublicKeyToken=b03f5f7f11d50a3a"/>
</configSections>
....
</configuration>
It's kind of ugly and if I know in the code that I want to use the
DefaultSection why can't I somehow tell the framework at runtime that I want
to add a new configSection removing the need to specify it in the application
configuration file?
--
Thanks,
Nick
(e-mail address removed)
remove "nospam" change community. to msn.com