Multiple elements in a configuration section

Hello All,

I would like to know whether it is possible to have multiple configuration elements with the same name within a custom section. Changing the element name to say "operation1" instead of "operation" (see sample file below) seems to work but i would like to use the same element name. I think i have to set something like maxOccurs=unbounded but not sure where to do it inside my custom classes. I have already implemented custom classes inherting from ConfigurationSection,ConfigurationElement and ConfigurationElementCollection to implement the stuff below. Am i missing something

Currently if i add multiple elements with the same name within the section i see the following error

"The element <operation> may only appear once in this section."

My custom config section looks like this

<Operations>

<operation opName="Test">

<rules>

<add name =""/>

<add name =""/>

<add name =""/>

</rules>

</operation>

<operation opName="Test2">

<rules>

<add name =""/>

<add name =""/>

<add name =""/>

</rules>

</operation>

</Operations>

Thanks for your help

Naru



Answer this question

Multiple elements in a configuration section

  • Rodrigo Chagas

    I agree with you there, I've spent a lot of time looking into this and despite some people saying it's easier in 2.0 I don't agree. My main struggle is implementing multiple tags with the same name too. Looks like I may have to revert to using the IConfigurationSectionHandler, which is supposed to be deprecated but a few of the 2.0 only classes (including ConfigurationSection) still implement this interface.

    Edit: OK I've tried again and I have it working, at this moment I'm not exactly sure how I did it, the code is all over the place (as you can imagine after much experimentation) but after I've cleaned things up I will give details, so for now the short answer yes it is possible to do it.


  • Attila Soos

    I see this in the code

    when i run my sample app i get this error message since i have two elements with the same name "operation" in the app.config.

    Any help with this is much appreciated


  • Robert Kozak

    I'm sorry probably i was not clear. I have implemented a custom section handler inheriting from ConfigurationSection and i have implemented classes from ConfigurationElementCollection and ConfigurationElement for custom section processing. My implementation sample is based of an MSDN sample where the custom section looks something like this

    <myurls>

    <url>

    <add name= ""/>

    <add name= ""/>

    </url>

    </myurls>

    Issue is when i add a additional element (<url>) to my app.config like the one shown below and build my custom section handler classes and run it i see the runtime exception "The element <url> may appear only once in this section". So i would like to know how can this be achieved through custom section handlers classes

    <myurls>

    <url>

    <add name= ""/>

    <add name= ""/>

    </url>

    <url>

    <add name= ""/>

    <add name= ""/>

    </url>

    </myurls>


  • JohnACE

    Where do you see this error In the editor, or in code

  • farsad ghaffarian

    I'm using the new ConfigurationSection class from .NET 2.0. I have inherited a custom class from the ConfigurationSection. I thought IConfigurationSectionHandler is the .NET 1.1 way of implementing custom sections. Please confirm
  • HMote

    Polan:
    Did you manage to figure out how you got it to work I want to do the same thing and would love to see some example code on how to do this. In my example I want to configure as below. The SubSystems-tag is expendable, but you get the idea. The problem is to get the multiple SubSystem-tags to work.

    (This is the very first real world scenario where I need custom config and the docs don't seem to cover what I need to know, which is frustrating)

    <OrganizationFoo>
    <ApplicationBar>
    <SubSystems>

    <SubSystem name="FirstSystemPluggedIn">
    <StandardAssemblies>
    <add assembly="StandardComponents32.dll" />
    <add assembly="StandardComponents33.dll" />
    <add assembly="StandardComponents34.dll" />
    </StandardAssemblies>
    <CustomAssemblies>
    <add assembly="CustomComponents34.dll" />
    </CustomAssemblies>
    </SubSystem>

    <SubSystem name="SecondSystemPluggedIn">
    <StandardAssemblies>
    <add assembly="StandardComponents11.dll" />
    <add assembly="StandardComponents23.dll" />
    </StandardAssemblies>
    <CustomAssemblies>
    <add assembly="CustomComponents23.dll" />
    </CustomAssemblies>
    </SubSystem>

    </SubSystems>
    </ApplicationBar>
    </OrganizationFoo>




  • Vitalijus

    Polan wrote:
    Looks like I may have to revert to using the IConfigurationSectionHandler, which is supposed to be deprecated but a few of the 2.0 only
    IConfigurationSectionHandler is not deprecated. There may be "new-and-improved" classes in .NET 2.0 for configuration files; but, IConfigurationSectionHandler is still there, it's not deprecated and there's no guidance from MS and the framework team to suggest it shouldn't be used.

  • Prashweenet

    Sorry, I assumed you were using a custom handler. If you're using a built in dictionary class to handle this section it doesn't support duplicate elements. You'll have to use a custom section handler (covered in other threads).

  • dbldown768

    Peter,

    Thanks. Somehow I had thought that ConfigurationSettings.GetConfig was obsolete as a result of IConfigurationSectionHandler being deprecated.

    I was unable to find documentation describing a ConfigurationSection's base except in terms of the Configuration element which is turn isn't described. Experimentally, I found that the configuration objects returned by ConfigurationSettings.GetConfig and ConfigurationManager.GetSection were the same IDictionary object (that can be queried using XPath). Would you have a pointer to something that will help me understand this relationship

    Thanks

    Mike


  • Sprite64

    You'll want to process the XML yourself. You'll want to create a class that implements the IConfigurationSectionHandler and process the XML in the Create() method.

  • monkeymagic

    mikebk wrote:
    > IConfigurationSectionHandler is not deprecated. There may be "new-and-improved"
    > classes in .NET 2.0 for configuration files; but, IConfigurationSectionHandler is still there,
    > it's not deprecated and there's no guidance from MS and the framework team to
    > suggest it shouldn't be used.

    The VS2005 help on "
    How to: Create Custom Configuration Sections Using IConfigurationSectionHandler" states "This topic uses the System.Configuration.IConfigurationSectionHandler interface, which has been deprecated in the .NET Framework version 2.0." The compiler generates messages like "warning CS0618: 'System.Configuration.ConfigurationSettings.GetConfig(string)' is obsolete: 'This method is obsolete,"

    That seems pretty definitive but admittedly this warning isn't in all help pages on IConfigurationSectionHandler . Is there some subtlety I've missed

    My specific interest is for a Windows service that already has fairly complex XML in most sections of its configuration file. Most sections use ConfigurationSettings.GetConfig to get the XML tree for the section and XPATH expressions to extract individual configurations datums.

    In this situation, there really doesn't seem to be a net benefit in switching to use the Configuration manager so I 'm hoping there's some kind of MS statement clarifying their intentions. Would you have a reference on this

    Thanks

    Mike
    How To: Create Custom Configuration Sections Using IConfigurationSectionHandler does not agree with the .NET binaries. Neither IConfigurationSectionHandler nor any of it's members are tagged as obsolete in .NET 2.0.

    The CS0618 warning you receive for System.Configuration.ConfigurationSettings.GetConfig is for a completely different class and has nothing to do with IConfigurationSectionHandler and does not imply IConfigurationSectionHandler is deprecated as well.



  • Jae

    Honestly, I haven't found any documentation on the classes like ConfigurationElement to be in depth enough to be able to implement multiple elements with the same name. All of the examples that deal with anything similar deal with a simple named pair dictionary.

    You'd need a ConfigurationSection object, at least one ConfigurationProperty object, and at least one ConfigurationElement object; plus the underlying class properties in each with the appropriate attributes. I find it *much easier* to use IConfigurationSectionHandler.



  • chadmv

    > IConfigurationSectionHandler is not deprecated. There may be "new-and-improved"
    > classes in .NET 2.0 for configuration files; but, IConfigurationSectionHandler is still there,
    > it's not deprecated and there's no guidance from MS and the framework team to
    > suggest it shouldn't be used.

    The VS2005 help on "
    How to: Create Custom Configuration Sections Using IConfigurationSectionHandler" states "This topic uses the System.Configuration.IConfigurationSectionHandler interface, which has been deprecated in the .NET Framework version 2.0." The compiler generates messages like "warning CS0618: 'System.Configuration.ConfigurationSettings.GetConfig(string)' is obsolete: 'This method is obsolete,"

    That seems pretty definitive but admittedly this warning isn't in all help pages on IConfigurationSectionHandler . Is there some subtlety I've missed

    My specific interest is for a Windows service that already has fairly complex XML in most sections of its configuration file. Most sections use ConfigurationSettings.GetConfig to get the XML tree for the section and XPATH expressions to extract individual configurations datums.

    In this situation, there really doesn't seem to be a net benefit in switching to use the Configuration manager so I 'm hoping there's some kind of MS statement clarifying their intentions. Would you have a reference on this

    Thanks

    Mike

  • tass_flint

    I'm having a similar issue ... did you ever figure this out

  • Multiple elements in a configuration section