none
How can I find what order I must place things in an app.config file? RRS feed

Answers

  • There is no order requirements for the sections within a config file.  You can place the sections in any order (and the elements within a section as well) you want provided the section is valid as defined by the section handler it will work.  The only exception to this rule is the <configSections> element which must be the first element in the config if it used.  Failure to follow this will cause an exception when the config is loaded.

    To get information about what elements and attributes can appear in what sections you'll have to go to the documentation.  MSDN has documentation for the allowable elements and attributes within the sections defined by Microsoft.  Third-party sections (like log4net) will provide their own documentation.  The .NET config subsystem is built upon a generic XML parser that passes each section (the elements under the root) to a section handler that is responsible for parsing out the elements.  Each section is defined by the rules of its type rather than by an XSD.  As such there isn't a validation schema you can look at.  However VS does ship with XSDs for the core sections such that Intellisense works in the editor.  You can use that if you want to see the schema that the core sections use.

    Personally I recommend that you put all the configurable sections toward the top so they are easier to manage.  Things like connection strings, app settings and service endpoints.  Sections that are rarely configured can be toward the bottom out of the way.  This would include web server settings, runtime options and component configurations.

    Michael Taylor
    http://blogs.msmvps.com/p3net

    • Marked as answer by DavidThi808 Monday, September 29, 2014 2:40 AM
    Friday, September 26, 2014 8:33 PM
    Moderator

All replies

  • With any class object in Net Library it doesn't make a difference of which order you fill any properties as long as you include the property name.  If you don't include the property name then the order that the object is defined is the same order you must use to file the class object.  Rather than worry about the order always include the property name.

    See code below

    using System;
    using System.Collections.Generic;
    using System.Linq;
    using System.Text;
    
    namespace ConsoleApplication1
    {
        class Program
        {
            static void Main(string[] args)
            {
                MyClass myClass = new MyClass()
                {
                    abc = 123,
                    def = "The quick brown fox jumped over the lazy dog"
                };
            }
        }
        public class MyClass
        {
            public int abc {get; set;}
            public string def {get; set;}
        }
    
    }
    


    jdweng

    Friday, September 26, 2014 5:49 PM
  • Joel I appreciate you trying to help but please don't answer the questions I ask. For some reason you don't understand what I am asking.

    In this case I am asking about the config settings in the app.exe.config file, not the order of methods in a .cs file.

    thanks - dave


    What we did for the last 6 months - Made the world's coolest reporting & docgen system even more amazing

    Friday, September 26, 2014 7:00 PM
  • I do understand the question.  The config file is XML which is like any other class object.  The XML tags are the property names inside the class object.  The order doesn't make a difference as long as the property name is included with the value.  When you don't include the property name you have to initialize the properties in the class in the order that they are defined.

    jdweng

    Friday, September 26, 2014 7:11 PM
  • The property names do matter. The app.exe.config has a schema.

    What we did for the last 6 months - Made the world's coolest reporting & docgen system even more amazing

    Friday, September 26, 2014 7:14 PM
  • Schema doesn't make a difference as long as the objects are at the same level.  So the order of the parents don't matter. And the order of the children of the same parent doesn't matter.   If you are getting errors then you probably misspelled a property.  Make sure the children are under the correct parent.  The name of the property in the XML must be the same as the name in the VS code including the case (lower/upper).  Some special characters are not valid (including Unicode) so also make sure you are not using any special characters.

    jdweng

    Friday, September 26, 2014 7:26 PM
  • Joel, please don't respond to questions I post. Please!

    What we did for the last 6 months - Made the world's coolest reporting & docgen system even more amazing

    Friday, September 26, 2014 7:41 PM
  • There is no order requirements for the sections within a config file.  You can place the sections in any order (and the elements within a section as well) you want provided the section is valid as defined by the section handler it will work.  The only exception to this rule is the <configSections> element which must be the first element in the config if it used.  Failure to follow this will cause an exception when the config is loaded.

    To get information about what elements and attributes can appear in what sections you'll have to go to the documentation.  MSDN has documentation for the allowable elements and attributes within the sections defined by Microsoft.  Third-party sections (like log4net) will provide their own documentation.  The .NET config subsystem is built upon a generic XML parser that passes each section (the elements under the root) to a section handler that is responsible for parsing out the elements.  Each section is defined by the rules of its type rather than by an XSD.  As such there isn't a validation schema you can look at.  However VS does ship with XSDs for the core sections such that Intellisense works in the editor.  You can use that if you want to see the schema that the core sections use.

    Personally I recommend that you put all the configurable sections toward the top so they are easier to manage.  Things like connection strings, app settings and service endpoints.  Sections that are rarely configured can be toward the bottom out of the way.  This would include web server settings, runtime options and component configurations.

    Michael Taylor
    http://blogs.msmvps.com/p3net

    • Marked as answer by DavidThi808 Monday, September 29, 2014 2:40 AM
    Friday, September 26, 2014 8:33 PM
    Moderator