Exception Handling in Task Parallel Library

Typically when you are using Task parallel library in .NET, the thread on which task would get executed would be different thread , so if you have  you have try catch blocked wrapped for the Task call and have wait on the task then you can catch the exception but it will not show the original exception which was raised. Take for e.g. below

    class Program
    {
        static void Main(string[] args)
        {
            try
            {
                Worker worker = new Worker();
                var task = Task.Factory.StartNew(worker.DoWork);
                task.Wait();
            }
            catch(Exception ex)
            {
                Console.WriteLine(ex.Message);
                Console.WriteLine(ex.GetType());
            }
            Console.ReadLine();
        }
    }

    public class Worker
    {
        public void DoWork()
        {
            throw new Exception("Testing TPL Library Exception Handling");
        }
    }

In the above case the output would be

One or more errors occurred.
System.AggregateException

To propagate all the exceptions back to the calling thread, the Task infrastructure wraps them in an AggregateException instance. The AggregateException exception has an InnerExceptions property that can be enumerated to examine all the original exceptions that were thrown, and handle (or not handle) each one individually. You can also handle the original exceptions by using the System.AggregateException.Handle method.
Even if only one exception is thrown, it is still wrapped in an AggregateException exception

So we will modify the code to accommodate the AggregateException

    class Program
    {
        static void Main(string[] args)
        {
            try
            {
                Worker worker = new Worker();
                var task = Task.Factory.StartNew(worker.DoWork);
                task.Wait();
            }
            catch (AggregateException ex)
            {
                foreach (var e in ex.InnerExceptions)
                {
                    Console.WriteLine(e.Message);
                    Console.WriteLine(e.GetType());
                }
            }
            catch (Exception ex)
            {
                Console.WriteLine(ex.Message);
                Console.WriteLine(ex.GetType());
            }
            Console.ReadLine();
        }
    }

    public class Worker
    {
        public void DoWork()
        {
            throw new Exception("Testing TPL Library Exception Handling");
        }
    }

 

In this case output would be
Testing TPL Library Exception Handling
System.Exception

HTH

Signal R Load balancing Issue

If you are using Signal R and and Signal R Hub as part of an ASP.net application which sits behind the loadbalancer with more than one machine then there is possiblity that you will start seeing this below error

SignalR – The connection id is in the incorrect format.

Just like when load balancing an ASP.NET website that uses Session, SignalR instances which are load balanced requires that all servers which handle SignalR requests must share a machine key. This is not mentioned in any documentation for SignalR/. ConnectionToken is encrypted using the machine key, when an application hits server 1 it is assigned a connectionToken generated using that machine’s machine key. If the application then hits server 2 with that assigned connectionToken, machine 2 cannot decrypt the token unless is has a matching machine key.

To solve this issue in your application web.config file you can add the machine key configuration

    
    <machineKey decryptionKey="EF1E7D088734F1B53F6594DE015FA9950B1379E4F2C3261E"
                validationKey="26EAACEB1553F966A8EC1B0304131B9D63CB81970B9204A04380189E040A84C0DC97303552434261E9445434392413EF881CF54892851955461A826805A78AA0" />

Now you must be wondering how can generate these keys, IIS manager helps you to generate those keys

• Open IIS Manager, host you are application website on the IIS, click on the site, then on the Features view tab, select machine key as shown below
  
• After selecting machine keys you will see following default options 
• Uncheck all the checkboxes and on the right side tab click on the “Generate Keys” option. 
• Post generating the keys, Click on apply, this will add the machine key configuration web site web.config file as shown above.

C# and MongDB Driver – Building Dynamic Queries based on Free Text Input

In case if you are using Mongo DB with .NET using C# MongoDB drivers and you would be typically querying Mongo DB data store using LINQ queries using static Lambda expressions. for e.g.

           IQueryable<User> userQuery = db.Query;
            ////Suppose I have to query "John" or "Mary" or "Thaine".
            ////Easiest option is to build static expression
            userQuery = userQuery.Where(u => (u.FirstName.ToLower().Contains("John") ||
                                u.FirstName.ToLower().Contains("Mary") ||
                                u.FirstName.ToLower().Contains("Thaine")));

Where user entity looks some thing like this

    [BsonIgnoreExtraElements]
    public class User
    {
        public ObjectId Id { get; set; }
        public string FirstName { get; set; }
        public string LastName { get; set; }
        public string Email { get; set; }
        public string Employer { get; set; }
        public Address Address { get; set; }
    }

    [BsonIgnoreExtraElements]
    public class Address
    {
        public string StreetName1 { get; set; }
        public string StreetName2 { get; set; }
        public string City { get; set; }
        public string State { get; set; }
        public string Zipcode { get; set; }
    }

Building static expressions is nothing new which we use more often then not. But what in in your application if there is requirement to perform search based of free text entered by user for e.g. in application UI there is text box to enter free text search with and / or/ not operator like “John or Mary or Thaine”. Then in case of static expression we do something like above.

But this is not what we want, we want the end user through UI send the query like above one and end user could send any combinations of and and or. Above solution of static expression does not fit the requirement. So here is where building dynamic expression tree comes in handy. Sample query that end user could be doing through UI could be “Mary and Thaine” or it could be “Mary or John or Thaine” or “Mary and New York”. So instead of static expressions we build a dynamic expression tree like show below

            IQueryable<User> userQuery = db.Query;
            string searchTerm = "John or Mary or Thaine";
            userQuery = userQuery.Where(
                CSharpMongoDynamicQueries.BuildAdvanceSearchExpressionTree<User>(searchTerm));

 

Where CSharpMongoDynamicQueries.BuildAdvanceSearchExpressionTree returns dynamic expression based on search term.

CSharpMongoDynamicQueries looks some thing like this.

    public class CSharpMongoDynamicQueries
    {
        #region Private static members
        private static readonly string AndOperator = " and ";
        private static readonly string OrOperator = " or ";
        private static readonly string NotOperator = " not ";
        private static readonly string[] stringSeparators = new string[] { AndOperator, OrOperator };
        #endregion


        /// <summary>
        /// Builds the advance search expression tree.
        /// This enables dynamic query on Following attributes
        /// FirstName, LastName, Employer, Email, Address.City.
        /// It can be enabled on other fields as well, but i have just restricted as a sample ot these set of fields.
        /// </summary>
        /// <typeparam name="TSource">The type of the source.</typeparam>
        /// <param name="searchTerm">The search term.</param>
        /// <param name="search">The search.</param>
        /// <returns></returns>
        public static Expression<Func<TSource, bool>> BuildAdvanceSearchExpressionTree<TSource>(string searchTerm)
        {
            ParameterExpression pe = Expression.Parameter(typeof(TSource), "User");
            string[] result = searchTerm.Split(stringSeparators, StringSplitOptions.RemoveEmptyEntries);
            var operatorIndexes = GetListOfSortedOperatorIndexes(searchTerm);
            Expression searchExpression = null;


            #region Employer
            var employerExpression = GetExpression<TSource>(result, searchTerm, "Employer", operatorIndexes, pe, false);
            searchExpression = searchExpression == null ? employerExpression : Expression.OrElse(searchExpression, employerExpression);
            #endregion

            #region Firstname
            var firstNameExpression = GetExpression<TSource>(result, searchTerm, "FirstName", operatorIndexes, pe, false);
            searchExpression = searchExpression == null ? firstNameExpression : Expression.OrElse(searchExpression, firstNameExpression);
            #endregion

            #region LastName
            var lastNameExpression = GetExpression<TSource>(result, searchTerm, "LastName", operatorIndexes, pe, false);
            searchExpression = searchExpression == null ? lastNameExpression : Expression.OrElse(searchExpression, lastNameExpression);
            #endregion

            #region Email
            var emailExpression = GetExpression<TSource>(result, searchTerm, "Email", operatorIndexes, pe, false);
            searchExpression = searchExpression == null ? emailExpression : Expression.OrElse(searchExpression, emailExpression);
            #endregion

            #region City
            var cityExpression = GetExpression<TSource>(result, searchTerm, "Address.City", operatorIndexes, pe, true);
            searchExpression = searchExpression == null ? cityExpression : Expression.OrElse(searchExpression, cityExpression);
            #endregion

            return Expression.Lambda<Func<TSource, bool>>(searchExpression, pe);
        }

        /// <summary>
        /// Gets the list of sorted operator indexes.
        /// </summary>
        /// <param name="input">The input.</param>
        /// <returns></returns>
        private static List<OperatorIndexes> GetListOfSortedOperatorIndexes(string input)
        {

            input = input.ToLower();
            string[] result = input.Split(stringSeparators, StringSplitOptions.RemoveEmptyEntries);

            List<OperatorIndexes> operatorIndexes = new List<OperatorIndexes>();
            var andOperatorIndexes = AllIndexesOf(input, stringSeparators[0]);
            var orOperatorIndexes = AllIndexesOf(input, stringSeparators[1]);

            if (andOperatorIndexes.Count > 0)
            {
                operatorIndexes.AddRange(andOperatorIndexes);
            }

            if (orOperatorIndexes.Count > 0)
            {
                operatorIndexes.AddRange(orOperatorIndexes);
            }

            if (operatorIndexes.Count > 0)
            {
                var sorterOperatorIndexes = operatorIndexes.ToList<OperatorIndexes>().OrderBy(v => v.Index).ToList<OperatorIndexes>();
            }
            return operatorIndexes;
        }

        /// <summary>
        /// Alls the indexes of.
        /// </summary>
        /// <param name="str">The string.</param>
        /// <param name="value">The value.</param>
        /// <returns></returns>
        /// <exception cref="System.ArgumentException">the string to find may not be empty;value</exception>
        private static List<OperatorIndexes> AllIndexesOf(string str, string value)
        {
            if (String.IsNullOrEmpty(value))
                throw new ArgumentException("the string to find may not be empty", "value");
            List<OperatorIndexes> indexes = new List<OperatorIndexes>();
            for (int index = 0; ; index += value.Length)
            {
                index = str.IndexOf(value, index);
                if (index == -1)
                    return indexes;
                indexes.Add(new OperatorIndexes
                {
                    Index = index,
                    Operator = value
                });
            }
        }


        /// <summary>
        /// Gets the expression.
        /// </summary>
        /// <typeparam name="TSource">The type of the source.</typeparam>
        /// <param name="searchTerms">The search terms.</param>
        /// <param name="keyword">The keyword.</param>
        /// <param name="propertyName">Name of the property.</param>
        /// <param name="operatorIndexes">The operator indexes.</param>
        /// <param name="pe">The pe.</param>
        /// <param name="addParentObjectNullCheck">if set to <c>true</c> [add parent object null check].</param>
        /// <returns></returns>
        private static Expression GetExpression<TSource>(string[] searchTerms, string keyword, string propertyName,
            List<OperatorIndexes> operatorIndexes, ParameterExpression pe, bool addParentObjectNullCheck)
        {
            // Compose the expression tree that represents the parameter to the predicate.
            Expression propertyExp = pe;
            foreach (var member in propertyName.Split('.'))
            {
                propertyExp = Expression.PropertyOrField(propertyExp, member);
            }
            Expression searchExpression = null;
            Expression finalExpression = null;
            Expression nullorEmptyCheck = null;
            var left = Expression.Call(propertyExp, typeof(string).GetMethod("ToLower", Type.EmptyTypes));
            var method = typeof(string).GetMethod("Contains", new[] { typeof(string) });
            for (int count = 0; count < searchTerms.Length; count++)
            {
                var searchTerm = searchTerms[count].ToLower();
                searchTerm = searchTerm.Replace("*", string.Empty);
                searchTerm = searchTerm.Replace("\"", string.Empty);
                Expression methodCallExpresssion = null;
                Expression rightExpression = null;
                if (searchTerm.Contains(NotOperator.TrimStart()))
                {
                    searchTerm = searchTerm.Replace(NotOperator.TrimStart(), string.Empty).Trim();
                    rightExpression = Expression.Constant(searchTerm);
                    methodCallExpresssion = Expression.Call(left, method, rightExpression);
                    methodCallExpresssion = Expression.Not(methodCallExpresssion);
                }
                else
                {
                    rightExpression = Expression.Constant(searchTerm);
                    methodCallExpresssion = Expression.Call(left, method, rightExpression);
                }

                if (count == 0)
                {
                    searchExpression = methodCallExpresssion;
                }
                else
                {
                    var conditionOperator = operatorIndexes[count - 1].Operator.Trim();
                    switch (conditionOperator)
                    {
                        case "and":
                            searchExpression = Expression.AndAlso(searchExpression, methodCallExpresssion);
                            break;
                        case "or":
                            searchExpression = Expression.OrElse(searchExpression, methodCallExpresssion);
                            break;
                        default:
                            break;
                    }
                }
            }

            if (addParentObjectNullCheck)
            {
                //Add Null check for Address Object before checking the value of City.
                var nullCheck = Expression.NotEqual(Expression.PropertyOrField(pe, "Address"), Expression.Constant(null, typeof(object)));
                nullorEmptyCheck = Expression.Not(Expression.Call(typeof(string), (typeof(string).GetMethod("IsNullOrEmpty")).Name, null, propertyExp));
                finalExpression = Expression.AndAlso(nullCheck, nullorEmptyCheck);
                finalExpression = Expression.AndAlso(finalExpression, searchExpression);
            }
            else
            {
                nullorEmptyCheck = Expression.Not(Expression.Call(typeof(string), (typeof(string).GetMethod("IsNullOrEmpty")).Name, null, propertyExp));
                finalExpression = Expression.AndAlso(nullorEmptyCheck, searchExpression);
            }

            return finalExpression;
        }
    }

    internal class OperatorIndexes
    {
        public int Index { get; set; }
        public string Operator { get; set; }
    }

 

This sample does “or” search on all the searchable fields but you can change it to target to certain fields so that your query becomes more clear and crisp.

GetExpression method is the heart of this it builds the dynamic expression tree for a particular field. Also expression tree is doing contains search you can change it to have exact search as well. This method add null check on the searchable fields and on the parent object as well (Address.City).

GetExpression expects to have searchTerms array as parameter, this array is build based on splitting SearchTerm based on and/or operator. This array is been built is appropriate sequence by private methods GetListOfSortedOperatorIndexes and AllIndexesOf, which are quite self explanatory, these methods could be more optimized as well.

Sample is tightly bound to User entity but this can be applied to any object which gets stored in mongo or any other NON SQL Db as long as it uses the concept of IQueryable and expression trees.

In above sample the for the sample query “John or Mary or Thaine”  CSharpMongoDynamicQueries returned expression tree something like shown below

User => (((((Not(IsNullOrEmpty(User.Employer)) 
AndAlso ((User.Employer.ToLower().Contains("john") 
OrElse User.Employer.ToLower().Contains("mary"))
OrElse User.Employer.ToLower().Contains("thaine"))) 
OrElse (Not(IsNullOrEmpty(User.FirstName)) 
AndAlso ((User.FirstName.ToLower().Contains("john") 
OrElse User.FirstName.ToLower().Contains("mary")) 
OrElse User.FirstName.ToLower().Contains("thaine")))) 
OrElse (Not(IsNullOrEmpty(User.LastName)) 
AndAlso ((User.LastName.ToLower().Contains("john") 
OrElse User.LastName.ToLower().Contains("mary")) 
OrElse User.LastName.ToLower().Contains("thaine")))) 
OrElse (Not(IsNullOrEmpty(User.Email)) 
AndAlso ((User.Email.ToLower().Contains("john") 
OrElse User.Email.ToLower().Contains("mary")) 
OrElse User.Email.ToLower().Contains("thaine")))) 
OrElse (((User.Address != null) 
AndAlso Not(IsNullOrEmpty(User.Address.City))) 
AndAlso ((User.Address.City.ToLower().Contains("john") 
OrElse User.Address.City.ToLower().Contains("mary")) 
OrElse User.Address.City.ToLower().Contains("thaine"))))

 

Source code for the sample can be found over here : Source Code

if you planning to run the sample please ensure to change the Mongo connection string in app.config. Change <dbusername>, <dbpassword> and <dbname> as appropriate as per your dev environment.

<add key="MongoConnectionString" value="mongodb://<dbusername>:<dbpassword>@ds030719.mlab.com:30719/<dbname>"/>

 

Please tweet me at @mytechnetnohows in case if I am not able to clarify things over here.

String Interpolation in C# 6

We regularly use string.Format or string.Concat or “+” operator to do all kinds of string manipulations.

public class Person
{
    public string FirstName { get; set; }
    public string MiddleInitial { get; set; }
    public string LastName { get; set; }
}

public void PrintPersonName(Person person)
{
    Console.WriteLine(string.Format("Full Name: {0} {1} {2}", person.FirstName, person.LastName, person.MiddleInitial));
}

String.Format and its cousins are very versatile, but their use is somewhat clunky and error prone. Particularly unfortunate is the use of numbered placeholders like {0} in the format string, which must line up with separately supplied arguments.

This creates new problems:

• You have to maintain the index yourself. If the number of arguments and index are not the same, it will generate error.
• If you need to add a new item to the string (not to the end), you have to update the whole indexing number.

For those reasons, we should use C# 6 new feature String interpolation.

public void PrintPersonNameNewWay(Person person)
{
            Console.WriteLine($"Full Name: {person.FirstName} {person.LastName} {person.MiddleInitial}");
}

The compiler now maintains the placeholders for you so you don’t have to worry about indexing the right argument because you simply place it right there in the string.  In String Interpolation, we simply prefix the string with a $ (much like we use the @ for verbatim strings). Then, we simply surround the expressions we want to interpolate with curly braces (i.e. { and }):

Garbage Collection – .NET – Demistified

 

When an application calls the new operator to create an object, there might not be enough address space left in the region to allocate the object. If insufficient space exists, then the CLR performs a GC.

For managing the lifetime of objects, some systems use a reference counting algorithm. In fact, Microsoft’s own Component Object Model (COM) uses reference counting. With a reference counting system, each object on the heap maintains an internal field indicating how many “parts” of the program are currently using that object. As each “part” gets to a place in the code where it no longer requires access to an object, it decrements that object’s count field. When the count field reaches 0, the object deletes itself from memory. The big problem with many reference counting systems is that they  do not handle circular references well. For example, in a GUI application, a window will hold a reference to a child UI element. And the child UI element will hold a reference to its parent window. These references prevent the two objects’ counters from reaching 0, so both objects will never be  deleted even if the application itself no longer has a need for the window.

Due to this problem with reference counting garbage collector algorithms, the CLR uses a referencing tracking algorithm instead. The reference tracking algorithm cares only about reference type variables, because only these variables can refer to an object on the heap; value type variables contain the value type instance directly. Reference type variables can be used in many contexts: static and instance fields within a class or a method’s arguments or local variables. We refer to all reference type variables as roots. Many objects on a heap are linked one to the other forming a chain, depending on which object is referenced by whom. There might be multiple such chains in the heap. The reference to the first object, i.e. the memory location to any such chain is called a Root. Every application has a set of such roots. E.g. the global and static object pointers, any local variable/parameter object pointers and any CPU registers containing pointers to objects.

All these roots are stored in the Application stack and identify storage locations, which refer to objects on the managed heap or to objects that are set to null. This list of active roots is maintained by the just-in-time (JIT) compiler and common language runtime, and is made accessible to the garbage collector’s algorithm.

When the CLR starts a GC, the CLR first suspends all threads in the process. This prevents threads from accessing objects and changing their state while the CLR examines them. Then, the CLR performs what is called the marking phase of the GC. First, it walks through all the objects in the heap setting a  bit (contained in the sync block index field) to 0. This indicates that all objects should be deleted. Then, the CLR looks at all active roots to see which objects they refer to. This is what makes the CLR’s GC a reference tracking GC. If a root contains null, the CLR ignores the root and moves on to examine the next root.

Any root referring to an object on the heap causes the CLR to mark that object. Marking an object means that the CLR sets the bit in the object’s sync block index to 1. When an object is marked, the CLR examines the roots inside that object and marks the objects they refer to. If the CLR is about to mark an already-marked object, then it does not examine the object’s fields again. This prevents an infinite loop from occurring in the case where you have a circular reference.

Below Figure shows a heap containing several objects. In this example, the application roots refer directly to objects A, C, D, and F. All of these objects are marked. When marking object D, the garbage collector notices that this object contains a field that refers to object H, causing object H to be marked  as well. The marking phase continues until all the application roots have been examined.

Once complete, the heap contains some marked and some unmarked objects. The marked objects must survive the collection because there is at least one root that refers to the object; we say that the object is reachable because application code can reach (or access) the object by way of the variable  that still refers to it. Unmarked objects are unreachable because there is no root existing in the application that would allow for the object to ever be accessed again.
Now that the CLR knows which objects must survive and which objects can be deleted, it begins the GC’s compacting phase. During the compacting phase, the CLR shifts the memory consumed by the marked objects down in the heap, compacting all the surviving objects together so that they are contiguous in memory. This serves many benefits. First, all the surviving objects will be next to each other in memory; this restores locality of reference reducing your application’s working set size, thereby improving the performance of accessing these objects in the future. Second, the free space is all contiguous as well, so this region of address space can be freed allowing other things to use it.
Finally, compaction means that there are no address space fragmentation issues with the managed heap as is known to happen with native heaps. When compacting memory, the CLR is moving objects around in memory. This is a problem because any root that referred to a surviving object now refers to where that object was in memory; not where the object has been relocated to. When the application’s threads eventually get resumed, they would access the old memory locations and corrupt memory. Clearly, this can’t be allowed and so, as part of the compacting phase, the CLR subtracts from each root the number of bytes that the object it referred to was shifted down in memory. This ensures that every root refers to the same object it did before; it’s just that the object is at a different location in memory.
After the heap memory is compacted, the managed heap’s NextObjPtr pointer is set to point to a location just after the last surviving object. This is where the next allocated object will be placed in memory. below figure shows the managed heap after the compaction phase. Once the compaction phase is complete, the CLR resumes all the application’s threads and they continue to access the objects as if the GC never happened at all.

If the CLR is unable to reclaim any memory after a GC and if there is no address space left in the processes to allocate a new GC segment, then there is just no more memory available for this process. In this case, the new operator that attempted to allocate more memory ends up throwing an OutOfMemoryException. Your application can catch this and recover from it but most applications do not attempt to do so; instead, the exception becomes an unhandled exception, Windows terminates the process, and then Windows reclaims all the memory that the process was using.
As a programmer, notice how the two bugs described at the beginning of this chapter no longer exist. First, it’s not possible to leak objects because any object not accessible from your application’s roots will be collected at some point. Second, it’s not possible to corrupt memory by accessing an object that was freed because references can only refer to living objects, since this is what keeps the objects alive anyway.
Important A static field keeps whatever object it refers to forever or until the AppDomain that the types are loaded into is unloaded. A common way to leak memory is to have a static field refer to a collection object and then to keep adding items to the collection object. The static field keeps the collection object alive and the collection object keeps all its items alive. For this reason, it is best to avoid static fields whenever possible.
Garbage Collection generations
The CLR’s GC is a generational garbage collector (also known as an ephemeral garbage collector,
although I don’t use the latter term in this book). A generational GC makes the following assumptions
about your code:

• The newer an object is, the shorter its lifetime will be.
• The older an object is, the longer its lifetime will be.
• Collecting a portion of the heap is faster than collecting the whole heap.

When initialized, the managed heap contains no objects. Objects added to the heap are said to be in generation 0. Stated simply, objects in generation 0 are newly constructed objects that the garbage collector has never examined. Figure below shows a newly started application with five objects allocated (A through E). After a while, objects C and E become unreachable.

When the CLR initializes, it selects a budget size (in kilobytes) for generation 0. So if allocating a new object causes generation 0 to surpass its budget, a garbage collection must start. Let’s say that objects A through E fill all of generation 0. When object F is allocated, a garbage collection must start. The garbage collector will determine that objects C and E are garbage and will compact object D, causing it to be adjacent to object B. The objects that survive the garbage collection (objects A, B, and D) are said to be in generation 1. Objects in generation 1 have been examined by the garbage collector once. The heap now looks like Figure below.

After a garbage collection, generation 0 contains no objects. As always, new objects will be allocated in generation 0. Figure BELOW shows the application running and allocating objects F through K. In addition, while the application was running, objects B, H, and J became unreachable and should have their memory reclaimed at some point.

Now let’s say that attempting to allocate object L would put generation 0 over its budget. Because generation 0 has reached its budget, a garbage collection must start. When starting a garbage collection, the garbage collector must decide which generations to examine. Earlier, WE said that when the CLR initializes, it selects a budget for generation 0. Well, it also selects a budget for generation 1. When starting a garbage collection, the garbage collector also sees how much memory is occupied by generation 1. In this case, generation 1 occupies much less than its budget, so the garbage collector examines only the objects in generation 0. Look again at the assumptions that the generational garbage collector makes. The first assumption is that newly created objects have a short lifetime. So generation 0 is likely to have a lot of garbage in it, and collecting generation 0 will therefore reclaim a  lot of memory. The garbage collector will just ignore the objects in generation 1, which will speed up the garbage collection process.

Obviously, ignoring the objects in generation 1 improves the performance of the garbage collector. However, the garbage collector improves performance more because it doesn’t traverse every object in the managed heap. If a root or an object refers to an object in an old generation, the garbage collector can ignore any of the older objects’ inner references, decreasing the amount of time required to build the graph of reachable objects. Of course, it’s possible that an old object’s field refers to a new object. To ensure that the updated fields of these old objects are examined, the garbage collector uses a mechanism internal to the JIT compiler that sets a bit when an object’s reference field changes. This support lets the garbage collector know which old objects (if any) have been written to since the last collection. Only old objects that have had fields change need to be examined to see whether they refer to any new object in generation 0.
A generational garbage collector also assumes that objects that have lived a long time will continue to live. So it’s likely that the objects in generation 1 will continue to be reachable from the application. Therefore, if the garbage collector were to examine the objects in generation 1, it probably wouldn’t  find a lot of garbage. As a result, it wouldn’t be able to reclaim much memory. So it is likely that collecting generation 1 is a waste of time. If any garbage happens to be in generation 1, it just stays there. The heap now looks like Figure below.

As you can see, all of the generation 0 objects that survived the collection are now part of generation 1. Because the garbage collector didn’t examine generation 1, object B didn’t have its memory reclaimed even though it was unreachable at the time of the last garbage collection. Again, after a collection, generation 0 contains no objects and is where new objects will be placed. In fact, let’s say that the application continues running and allocates objects L through O. And while running, the application stops using objects G, L, and M, making them all unreachable. The heap now looks like figure below

Let’s say that allocating object P causes generation 0 to exceed its budget, causing a garbage collection to occur. Because the memory occupied by all of the objects in generation 1 is less than its budget, the garbage collector again decides to collect only generation 0, ignoring the unreachable objects in generation 1 (objects B and G). After the collection, the heap looks like Figure below.

In Figure above, you see that generation 1 keeps growing slowly. In fact, let’s say that generation 1 has now grown to the point in which all of the objects in it occupy its full budget. At this point, the application continues running (because a garbage collection just finished) and starts allocating objects  P through S, which fill generation 0 up to its budget. The heap now looks like Figure below.

When the application attempts to allocate object T, generation 0 is full, and a garbage collection must start. This time, however, the garbage collector sees that the objects in generation 1 are occupying so much memory that generation 1’s budget has been reached. Over the several generation  0 collections, it’s likely that a number of objects in generation 1 have become unreachable (as in our example). So this time, the garbage collector decides to examine all of the objects in generation 1 and generation 0. After both generations have been garbage collected, the heap now looks like Figure below.

As before, any objects that were in generation 0 that survived the garbage collection are now in generation 1; any objects that were in generation 1 that survived the collection are now in generation 2. As always, generation 0 is empty immediately after a garbage collection and is where new objects  will be allocated. Objects in generation 2 are objects that the garbage collector has examined two or more times. There might have been several collections, but the objects in generation 1 are examined only when generation 1 reaches its budget, which usually requires several garbage collections of  generation 0.

The managed heap supports only three generations: generation 0, generation 1, and generation 2; there is no generation 3.23 When the CLR initializes, it selects budgets for all three generations. However, the CLR’s garbage collector is a self-tuning collector. This means that the garbage collector learns about your application’s behavior whenever it performs a garbage collection. For example, if your application constructs a lot of objects and uses them for a very short period of time, it’s possible that garbage collecting generation 0 will reclaim a lot of memory. In fact, it’s possible that the memory for all objects in generation 0 can be reclaimed. If the garbage collector sees that there are very few surviving objects after collecting generation 0, it might decide to reduce the budget of generation 0. This reduction in the allotted space will mean that garbage collections occur more frequently but will require less work for the garbage collector, so your process’s working set will be small. In fact, if all objects in generation 0 are garbage, a garbage collection doesn’t have to compact any memory; it can simply set NextObjPtr back to the beginning of generation 0, and then the garbage collection is performed. Wow, this is a fast way to reclaim memory!
Note The garbage collector works extremely well for applications with threads that sit idle at the top of their stack most of the time. Then, when the thread has something to do, it wakes up, creates a bunch of short-lived objects, returns, and then goes back to sleep. Many applications follow this  architecture. For example, GUI applications tend to have the GUI thread sitting in a message loop most of its life. Occasionally, the user generates some input (like a touch, mouse, or keyboard event), the thread wakes up, processes the input and returns back to the message pump. Most objects created to  process the input are probably garbage now. Similarly, server applications tend to have thread pool threads sitting in the pool waiting for client
requests to come in. When a client request comes in, new objects are created to perform work on behalf of the client request. When the result is sent back to the client, the thread returns to the thread pool and all the objects it created are garbage now.
On the other hand, if the garbage collector collects generation 0 and sees that there are a lot of
surviving objects, not a lot of memory was reclaimed in the garbage collection. In this case, the
garbage collector will grow generation 0’s budget. Now, fewer collections will occur, but when they do,  a lot more memory should be reclaimed. By the way, if insufficient memory has been reclaimed after a  collection, the garbage collector will perform a full collection before throwing an  OutOfMemoryException.
Throughout this discussion, we’ve been talking about how the garbage collector dynamically modifies generation 0’s budget after every collection. But the garbage collector also modifies the budgets of generation 1 and generation 2 by using similar heuristics. When these generations are garbage collected, the garbage collector again sees how much memory is reclaimed and how many objects survived. Based on the garbage collector’s findings, it might grow or shrink the thresholds of these generations as well to improve the overall performance of the application. The end result is that the garbage collector fine-tunes itself automatically based on the memory load required by your application—this is very cool!

Large Objects
There is one more performance improvement you might want to be aware of. The CLR considers each single object to be either a small object or a large object. So far, in this chapter, I’ve been focusing on small objects. Today, a large object is 85,000 bytes or more in size.24 The CLR treats large objects slightly differently that how it treats small objects:

• Large objects are not allocated within the same address space as small objects; they are allocated elsewhere within the process’ address space.
• Today, the GC doesn’t compact large objects because of the time it would require to move them in memory. For this reason, address space fragmentation can occur between large objects within the process leading to an OutOfMemoryException being thrown. In a future version of the CLR, large objects may participate in compaction.
• Large objects are immediately considered to be part of generation 2; they are never in generation 0 or 1. So, you should create large objects only for resources that you need to keep alive for a long time. Allocating short-lived large objects will cause generation 2 to be collected more frequently, hurting performance. Usually large objects are large strings (like XML or JSON) or byte arrays which you use for I/O operations, such as reading bytes from a file or network

In the future, the CLR could change the number of bytes required to consider an object to be a large object. Do not count 85,000 being a constant into a buffer so you can process it. For the most part, large objects are transparent to you; you can simply ignore that they exist and that they get special treatment until you run into some unexplained situation in your program.

P.S. Thanks to Jefrey Ritcher’s Book CLR Via C# for the content 🙂

Tech Interview App – Android Store – Try it and let me know Feedback…

Try my Android Store App – App Contains Categorized Q&A for tech categories focus on OSS stack (Angular, Node) for building hybrid apps as well as  MS Stack (.NET, ASP.NET, MVC, Web API…). Provides Question Count Statistics as well categorized question count break down. Questions and Answers periodically without app upgrade.

Tech Interview App

App is built using HTML 5, Angular JS and Web API in the back Ground.

Plan is to add Questions Weekly to the Respository and make more enhancements :).

Send Feedback…..

Whats new in C# 6.0

• Exception Filters : Exception filters are a CLR capability that is exposed in Visual Basic and F#, but hasn’t been in C# – until now. If the parenthesized expression after ‘if’ evaluates to true, the catch block is run, otherwise the exception keeps going. Basically Exception Filter is one of the new features of C# 6.0 that allows us to specify a conditional clause for each catch block. In other words now we can write a catch block that will handle the exception of a specific type only when a certain condition is true that is written in an exception filter clause. First we see a code snippet of an Exception Filter then we will learn more about it.

      static void Main(string[] args)
      {
          try
          {
              throw new ArgumentNullException("Arg1");
              //throw new ArgumentNullException("Arg2");
          }
          catch (ArgumentNullException ex) if (ex.Message.Contains("Arg1"))
          {
              Console.WriteLine("Error Message : " + ex);
          }
          catch (ArgumentNullException ex) if (ex.Message.Contains("Arg2"))
          {
              Console.WriteLine("Error Message : " + ex);
          }
      }
  }

• Await in catch and finally blocks : This has been disallowed until now, now with C# 6.0 we can use await int catch and finally block.

      public async void Process()
      {
          ILogger logger = new Logger();
          try
          {
   
          }
          catch (ArgumentNullException ex)
          {
              Console.WriteLine("Error Message : " + ex);
              await logger.LogError(ex);
          }
          catch (Exception ex)
          {
              Console.WriteLine("Error Message : " + ex);
              await logger.LogError(ex);
          }
          finally
          {
              await logger.Log("Method Execution Process() Completed");    
          }
      }
  }

  Logger Implementation looks some thing like this

  public interface ILogger
   {
       Task<bool> LogError(Exception ex);
   
       Task<bool> Log(string message);
   }
   public class Logger : ILogger
   {
       public async Task<bool> LogError(Exception ex)
       {
           await Task.Run(() => {
               // Log to Windows Log or do custom logging
           });
           return true;
       }
   
       public async Task<bool> Log(string message)
       {
           await Task.Run(() => {
               // Log to Windows Log or do custom logging
           });
           return true;
       }
   }

• Auto-property initializers: These are similar to initializers on fields. Initialize property is repetitive task, and cannot be done in the same line as we can can done for fields.  Property can be initialized only in the constructor, beside the filed which can be initialized in the same line where it is declared.

   public class Employee
   {
       private string _firstName = "Default Name";
       public string FirstName { get; set; }
       public Employee()
       {
           FirstName = _firstName;
       }
   
   }

  The new feature in C# 6.0 defines Auto-Property initializer alowing property to be initialized like fields. The following code snippet shows the Auto-Property Initializer;

  public class Employee
   {
       private static string _lastName = "Gote";
       public string FirstName { get; set; } = "Aamol";
   
       public string LastName { get; set; } = "Gote";
   
       //Property with Private Setter
       public string Email { get; } = _lastName;
   }

• Expression-bodied function members: It allow methods, properties and other kinds of function members to have bodies that are expressions instead of statement blocks, just like with lambda expressions.Expression-bodied function members allow properties, methods, operators and other function members to have bodies as lambda like expressions instead of statement blocks. Thus reducing lines of codes and clear view of the expressions. Now in C# 6.0, instead of writing the whole property body using getters/setters, you can now just use the lambda arrow (“=>”) to return values. Yu can write expressions for methods/functions which returns value to the caller example below

  public string GetFullName(string firstName, string lastname, string middleInitial) => string.Concat(firstName, " ", lastname, " ", middleInitial);
  

  Same can be applied to properties as well

  public string StreetAddress => "1 Microsoft Way Redmond";
  

• Import Features : using static is a new kind of using clause that lets you import static members of types directly into scope.

  using System;
  using System.Collections.Generic;
  using System.Linq;
  using System.Text;
  using System.Threading.Tasks;
  using System.Console;
   
  namespace WhatNewInCharp6
  {
      class Program
      {
          static void Main(string[] args)
          {
              WriteLine("Inside Main");
          }
      }
  }

• Null Conditional Operator: The NullReferenceException is night mare for any developer. Almost every created object must be check against null value before we call some of its member.C# 6.0 also introduced Null-Conditional operator that enable developers to check the null value with in an object reference chain. The null – conditional operator ( ?.) , returns null if anything in the object reference chain in null. This avoid checking null for each and every nested objects if they are all in referenced and having null values.
  For E.g. Consider below classes

  public class Person
  {
      public Address Address { get; set; }
  }
   
  public class Address
  {
      public Address HomeAddress { get; set; }
      public Address OfficeAddress { get; set; }
      public string StreetAddress { get; set; }
      public string City { get; set; }
      public string State { get; set; }
      public string Zip { get; set; }
  }

  I need to access Home Address for Person Object Passed and then print it, in older appraoch i had to do all nested null check like shown below

  public void PrintHomeAddress(Person person)
  {
      if (person != null && person.Address != null & person.Address.HomeAddress != null)
      {
          Console.WriteLine(string.Concat(person.Address.HomeAddress.StreetAddress, Environment.NewLine, person.Address.HomeAddress.State, person.Address.HomeAddress.Zip));
      }
  }

  But with C# 6.0 null conditional operator same can be achieved like show below

  public void PrintHomeAddressNewWay(Person person)
  {
      if (person?.Address?.HomeAddress != null)
      {
          Console.WriteLine(string.Concat(person.Address.HomeAddress.StreetAddress, Environment.NewLine, person.Address.HomeAddress.State, person.Address.HomeAddress.Zip));
      }
  }

  Instead of check each and individual objects, using ?. we can check entire chain of reference together and whenever there is a null values, it return null.
  The “?.” operator is basically saying, if the object to the left is not null, then fetch what is to the right, otherwise return null and halt the access chain.

• nameOf Expressions: nameof expressions are a new form of string literal that require more syntax and are more restricted than the existing kinds. Oftentimes you need to provide a string that names some program element: when throwing an ArgumentNullException you want to name the guilty argument; when raising a PropertyChanged event you want to name the property that changed, etc. Using ordinary string literals for this purpose is simple, but error prone. You may spell it wrong, or a refactoring may leave it stale. nameof expressions are essentially a fancy kind of string literal where the compiler checks that you have something of the given name, and Visual Studio knows what it refers to, so navigation and refactoring will work.
  Earlier for arguement null exception you would do some thing like shown below, but what if parameter name person changes, then you change the exception message as well

  public void PrintOfficeAddress(Person person)
   {
      if (person == null) throw new ArgumentNullException("person is null");
   }

  With C# 6.0 you use nameOf Operator which will automatically factor in your variable name change in case code gets re-factored or parameter name changes

  public void PrintOfficeAddressNewWay(Person person)
  {
      if (person == null) throw new ArgumentNullException(nameof(person) + " is null");
  }
  

• String Interpolation: We regularly use string.Format or string.Concat or “+” operator to do all kinds of string manipulations like shown below

  public void PrintPersonName(Person person)
  {
      Console.WriteLine(string.Format("Full Name: {0} {1} {2}", person.FirstName, person.LastName, person.MiddleInitial));
  }

  String interpolation lets you more easily format strings. String.Format and its cousins are very versatile, but their use is somewhat clunky and error prone. Particularly unfortunate is the use of numbered placeholders like {0} in the format string, which must line up with separately supplied arguments

  With C# 6.0 above can be achieved easily as shown below

  public void PrintPersonNameNewWay(Person person)
  {
      Console.WriteLine("Full Name: \{person.FirstName} \{person.LastName} \{person.MiddleInitial}");
  }

• Dictionary Initializer – You can initialize dictionary in following manner

  Dictionary<string, Person> persons = new Dictionary<string, Person>()
   {
       ["EMPID1"] = new Person() { FirstName = "Aamol", LastName = "Gote" },
       ["EMPID2"] = new Person() { FirstName = "John", LastName = "Doe" },
       ["EMPID3"] = new Person() { FirstName = "Mary", LastName = "Lamb" }
   };

  If the Key is not string but some object then syntax would be some thing like below

  Dictionary<Identifier, Person> personsWithIdentifiers = new Dictionary<Identifier, Person>()
  {
      [new Identifier() { Id = new Guid(), SSN = "111-222-2345" }] = new Person() { FirstName = "Aamol", LastName = "Gote" },
      [new Identifier() { Id = new Guid(), SSN = "345-222-2345" }] = new Person() { FirstName = "John", LastName = "Doe" },
      [new Identifier() { Id = new Guid(), SSN = "999-222-2345" }] = new Person() { FirstName = "Mary", LastName = "Lamb" }
  };

Following features have not made in to VS2015 Preview

• Primary constructors in C# (along with initializers in structs)
• Declaration expressions in C# / Out parameters in VB

Source Code be downloaded from here

String Reversal Patterns/Algorithms

String Reversal with Swap algorithm – trivial one and average performance and the overhead of copying twice one to char array and other to original as strings are immutable. Extra variable is used as temp unnecessarily

    static string ReverseStringWithTemp(string sourceString)

        {

            char[] inputStream = sourceString.ToCharArray();

            for (int i = 0, j = sourceString.Length –  1; i < j; i++, j–)

            {

                char temp = inputStream[i];

                inputStream[i] = inputStream[j];

                inputStream[j] = temp;

            }

            return new string(inputStream);

        }

String Reversal with Copy to Char Array – trivial one an average performance and the overhead of copying twice one to char array and other to original as strings are immutable, no use of temp variable so memory efficient normal reversal

        static string ReverseStringWithoutTemp(string sourceString)

        {

            char[] inputStream = sourceString.ToCharArray();

            for (int i = 0, j = sourceString.Length – 1; i < j; i++, j–)

            {

                inputStream[j] = sourceString[i];

                inputStream[i] = sourceString[j];

            }

            return new string(inputStream);

        }

String Reversal with Stack – uses FILO structure for string reversal. Performance is almost equal to the normal reversals. Note that two loops are being used

        static string ReverseStringWithStack(string sourceString)

        {

            Stack<char> reverseString = new Stack<char>();

            for(int i = 0; i < sourceString.Length;i++)

            {

                reverseString.Push(sourceString[i]);

            }

            string targetString = string.Empty;

            while (reverseString.Count > 0)

            {

                targetString += reverseString.Pop();

            }

 

            return targetString;

        }

String Reversal with Bitwise XORing and quick one too without extra memory usage

        static string ReverseStringWithBitWiseXOR(string sourceString)

        {

            char[] inputStream = sourceString.ToCharArray();

 

            for (int i = 0, j = sourceString.Length – 1; i < j; i++, j–)

            {

                inputStream[i] ^= inputStream[j];

                inputStream[j] ^= inputStream[i];

                inputStream[i] ^= inputStream[j];

            }

            return new string(inputStream);

        }

In c# x1 ^= x2 equals to x1 = x1 ^ x2 where ^ is the bitwise XOR.

Let’s say we want to switch 2 binary values x1 = 100 and x2 = 111 so that x1 = 111 and x2 = 100.

XOR (Exclusive OR) table 0 XOR 0 = 0 0 XOR 1 = 1 1 XOR 0 = 1 1 XOR 1 = 0 First operation: x1 = x1 XOR x2 x1: 1 0 0 x2: 1 1 1 New x1: 0 1 1 Second operation x2 = x2 XOR x1 x1: 0 1 1 x2: 1 1 1 New x2: 1 0 0 Third operation: x1 = x1 XOR x2 x1: 0 1 1 x2: 1 0 0 New x1: 1 1 1

We now have x1 = 111 and x2 = 100.

C# Dynamic Keyword

dynamic is a new static type that acts like a placeholder for a type not known until runtime. Once the dynamic object is declared, it is possible to call operations, get and set properties on it, even pass the dynamic instance pretty much as if it were any normal type.

The dynamic keyword influences compilation. A dynamic variable, parameter or field can have any type. Its type can change during runtime. The downside is that performance suffers and you lose compile-time checking.

Dynamic is advanced functionality. It can be useful. But usually it should be avoided. It erases many benefits of the C# language.

Comparison with var
dynamic variable and var variable both can store any type of value but its required to initialize ‘var’ at the time of declaration.

Compiler doesn’t have any information about the ‘dynamic’ type of variable. var is compiler safe i.e compiler has all information about the stored value, so that it doesn’t cause any issue at run-time.

Dynamic type can be passed as function argument and function also can return it. Var type can not be passed as function argument and function can not return object type. This type of variable can work in the scope where it defined.

dynamic: Useful when coding using reflection or dynamic language support or with the COM objects, because we require to write less amount of code.

“throw” V/S “throw ex”

Is there a difference between “throw” and “throw ex”?

Yes – throw re-throws the exception that was caught, and preserves the stack trace. throw ex throws the same exception, but resets the stack trace to that method. Unless you want to reset the stack trace (i.e. to shield public callers from the internal workings of your library), throw is generally the better choice, since you can see where the exception originated

In the “throw ex”, the stack trace is truncated, what this means is that when you look at the stack trace, it will look as if the exception originated in your code. This isn’t always the case, particularly if you are bubbling up a CLR generated exception (like a SqlException). This is a problem known as “breaking the stack”, because you no longer have the full stack trace information. This happens because you are in essence creating a new exception to throw.

By using “throw” by itself, you preserve the stack trace information. You can confirm this by looking at the IL generated for these two code blocks. This makes the difference very obvious since in the first example the IL instruction called is “throw” while in the second the instruction is called “rethrow”.

Before you run and change all of your code, there are still places where “throw ex” is appropriate. There are times when you want to add information to the exception that was caught or change it into a more meaningful exception.

To Summarize

• Only catch exceptions if they are important to you and you need to do some sort of cleanup as a result.
• If you need to bubble an exception up the chain, use “throw” by itself.
• If you need to add information to the exception or repackage it, always pass the original exception as the inner exception.