Category: .NET Framework

Suppose we  want to create a custom config section in this following manner

 

<queryTypes>

    <queryType name=“qt1“ value=“qt1 value“></queryType>

    <queryType name=“qt2“ value=“qt2 value“></queryType>

</queryTypes>

 

For implementing the above custom section we need to first define a class inheriting from ConfigurationSection class

 

Add reference to System.Configuration dll.

 

Create a new config section class in the following manner

 

    // implement ConfiguraionSection class

    class QueryTypesSection : ConfigurationSection

    {

        public QueryTypesSection()

        {

        }

        [ConfigurationProperty(“”, IsDefaultCollection = true)]

        public QueryTypesCollection QueryTypes

        {

            get

            {

                return (QueryTypesCollection)base[“”];

            }

 

        }

 

    }

    // Represents a configuration element containing a collection of child elements   

    public sealed class QueryTypesCollection : ConfigurationElementCollection

    {

        protected override ConfigurationElement CreateNewElement()

        {

            return new QueryTypeElement();

        }

        protected override object GetElementKey(ConfigurationElement element)

       

        {

           

            return ((QueryTypeElement)element).Name;

        }

        public override ConfigurationElementCollectionType CollectionType

        {

            get

            {

                return ConfigurationElementCollectionType.BasicMap;

            }

        }

        protected override string ElementName

        {

            get

            {

                return “queryType”;

            }

        }

    }

    // Defining QueryTypeElement with name and value attribute

    public sealed class QueryTypeElement : ConfigurationElement

    {

        // defining name attribute

        [ConfigurationProperty(“name”, IsRequired = true)]

        public string Name

        {

            get

            {

                return (string)this [“name”];

            }

            set

            {

                this[“name”] = value;

            }

        }

 

        // defining value attribute

        [ConfigurationProperty(“value”, IsRequired = true)]

        public string Value

        {

            get

            {

                return (string)this[“value”];

            }

            set

            {

                this[“value”] = value;

            }

        }

 

    }

 

 

Now to register your custom section do the following

 

<configSections>

<section name=“queryTypes“ type=“namespace.QueryTypesSection, namespace “ />

</configSections>

 

 

And to use it within the application

 

 

  QueryTypesSection queryTypeSection = (QueryTypesSection)ConfigurationManager.GetSection(“queryTypes”);

            QueryTypesCollection  queryTypeCollection = queryTypeSection.QueryTypes;

            foreach (QueryTypeElement se in queryTypeCollection)

            {

                string name=se.Name;

                string value = se.Value;

            }

 

 

That’s it…

At times instead of using appSettings section we would like to define our own custom section within configuration file.

 

Suppose we  want to create a custom config section in this following manner

 

<SimplConfigSection id=“myID“ name=“myName“ />

 

For implementing the above custom section we need to first define a class inheriting from ConfigurationSection class

 

Add reference to System.Configuration dll.

 

Create a new config section class in the following manner

 

// inherit the class ConfigurationSection

    class SimpleConfigSection : ConfigurationSection

    {

        public SimpleConfigSection()

        {

        }

 

        // using ConfigurationProperty attribute to define the attribute

        [ConfigurationProperty(“id”,IsRequired = true)]

        public String ID

        {

            get

            { return (String)this[“id”]; }

            set

            { this[“id”] = value; }

        }

        // using ConfigurationProperty attribute to define the attribute

        [ConfigurationProperty(“name”, IsRequired = true)]

        public String Name

        {

            get

            { return (String)this[“name”]; }

            set

            { this[“name”] = value; }

        }

    }

 

 

Now to register your custom section do the following

 

<configSections>

<section name=“SimplConfigSection“            type=“Namespace.SimpleConfigSection, Namespace“ />

</configSections>

 

 

And to use it within the application

 

SimpleConfigSection simpleConfig = (SimpleConfigSection)ConfigurationManager.GetSection(“SimplConfigSection”);

            string id = simpleConfig.ID;

            string name = simpleConfig.Name;

 

 

That’s it …

Garbage collection in Microsoft.NET is based on Mark and Compact algorithm and concept of generations.

 

Mark and Compact Algorithm

 

When an application is started a given amount of address space is allocated to the application which is called managed heap. We can make use of GetTotalMemory method of GC class to get the number of bytes currently allocated in managed memory. When a new object has to be instantiated and there isn’t enough space in the application’s managed heap, the garbage collection process runs.

 

• Garbage collector generates a list of all the application’s objects that are still in scope.

 

• The garbage collector steps through the managed heap, looking for any object that is not present in this list.

 

• The garbage collector marks the objects that are out of scope. The space these objects were taking up is freed.

 

• After the garbage collector has iterated through the managed heap, it moves the references to all the objects down to the beginning of the heap. All the object references are therefore stored contiguously in the heap.

 

 

Let’s take a simple example

 

Suppose when an application is started, objects A, B, C and D are instantiated, and references to these objects are placed on the managed heap.

 

Object D

Object C

Object B

Object A

 

Suppose later in the life of application, object E needs to be instantiated. Now there isn’t enough space in the managed heap so garbage collection needs to be performed. Objects B and C have gone out of scope.

 

When garbage collection is started, a list of all the objects that are still in scope is generated, here the list will contain object A and D, than it iterates through the managed heap, looking for the objects that are not present in the list. These objects are marked as unreachable and the managed heap is compacted. A reference to Object E is then placed on the heap.

 

 

Object D

Object C

Object B

Object A

 

To

 

Object E

Object D

Object A

 

 

 

Generations

 

Here in the above case it could be very expensive to step through the entire heap, looking for marked objects. To make this process more efficient, Microsoft.NET implements concept of generations. The theory of generations assumes that the older an object is, the less likely it is out to be out of scope during garbage collection. Therefore, it is most efficient to check the newest objects first and then check the older objects if space is still needed.

 

There are three generations: Generation 0, 1 and 2. When a garbage collection is performed, it collects only objects in Generation 0. If there is still not enough space to allocate a new object, then garbage collector moves on to Generation 1, and then if necessary, it moves to Generation 2 objects.

For e.g. consider an application that has object A in generation 2, B and C in generation 1 and D, E, F in Generation 0.

 

 

Object F	Gen 0
Object E	Gen 0
Object D	Gen 0
Object C	Gen 1
Object B	Gen 1
Object A	Gen 2

 

Now the application attempts to allocate space to Object G, but it cannot, so a garbage collection is required.

 

Say objects C, D and E have gone out of scope.

 

After the garbage collection, objects D and E are collected. Even though Object C had gone out of scope, the garbage collector only collected from Generation 0. If more space had been required than Object C, from Generation 1, would also have been collected.

 

And one more thing, the Object F will be moved to Generation 1 because it has survived one garbage collection. The garbage collector did not collect from Generation 1; therefore Object C is still within generation 1.

 

Now the managed heap would look something like this

 

Object G	Gen 0
Object F	Gen 1
Object C	Gen 1
Object B	Gen 1
Object A	Gen 2

  

 

Bye ..