.NET Tips : List of my short tips

Hi Friends,

As I have already told you that I have been publishing short tips in DailyDotnetTips regularly, it is time to share the links with you to keep you updated. Please read these short tips from me and give your feedback.

1. Using ReaderWriterLock over Monitor for Thread Locking
2. What is the use of IsBackground property of Thread?
3. Co-Ordinated Thread Shutdown with and without using CancellationTokenSource
4. Writing a Stretchable ContentControl in WPF
5. What is Visual Tree and Logical Tree in WPF?
6. Dealing with HWND in WPF
7. Hosting a WPF control inside a Windows Form
8. Accessing local assemblies in XAML
9. Difference between a UserControl and a CustomControl
10. Hosting a Windows Forms control inside a WPF
11. Use x:Shared to write your FrameworkElements directly as Resource
12. Use BitmapScalingMode to ensure your rendering of Image is perfect
13. Object hierarchy of NULL
14. Lazy Initializer to defer expensive Object creation in .NET 4.0
15. Working with Co-Variance and Contra-Variance in .NET 4.0
16. Using Complex Numbers in .NET 4.0
17. Working with BigInteger in .NET 4.0
18. Working with SortedSet in .NET 4.0
19. Common Table Expressions in SQL Server
20. Compiler directive #Pragma reference

So here are my last 20 short tips posted on DailyDotnetTips. 

I hope you will like these tips. For full list of all the tips and the latest updates, check this link. 

Happy Coding. 

Thanks. 

Internals of a Delegate

Strange Rules of Delegate

Well, at recent times, at least after the introduction of .NET framework 3.5 the use of Delegates in a program has increased quite a bit. Now almost every people in .NET language must at least somehow used delegates on their daily programming activities. It might be because of the fact that the use of delegates has been simplified so much with the introduction of lambda expressions in .NET framework 3.5 and also the flexibility to pass delegates over other libraries for decoupling and inversion of control in applications. Hence, we can say the way of writing code in .NET environment has been changed considerably in recent times.

Introduction

If you want the most simple and somewhat vague idea about delegates I would say a delegate is actually a reference to a method so that you might use the reference as you use your object reference in your code, you can send the method anywhere in your library or even pass to another assembly for its execution, so that when the delegate is called, the appropriate method body will get executed. Now, to know a more concrete and real life example, I must consider you to show a code :

public delegate int mydelegate(int x);
        public class A
        {
            public mydelegate YourMethod { get; set; }

            public void ExecuteMe(int param)
            {
                Console.WriteLine("Starting execution of Method");
                if (this.YourMethod != null)
                {
                    Console.WriteLine("Result from method : {0}", this.YourMethod(param));
                }
                Console.WriteLine("End of execution of Method");
            }
        }
        

        static void Main(string[] args)
        {

            //int x = 20;
            //int y = 50;

            A a1 = new A();

            a1.YourMethod = Program.CallMe;


            a1.ExecuteMe(20);

            Console.Read();
    }
     public static int CallMe(int x)
        {
            return x += 30;
        }

}

In the above code, I have explicitly declared a delegate and named it mydelegate. The name of the delegate will indicate that it is a type that can create reference to a method which can point to a method which have same signature as defined in it. Clearly If you quickly go through the code defined above, the property YourMethod can point to a signature which has same signature as declared to mydelegate. Hence, I can pass a method CallMe easily to Type A, so that when the object of A calls the delegate, it executes the method CallMe.

ADO.NET - Some Internals Uncovered

During the early phaze of your career, when you just have started learning about .NET technology, you might have came across the sentence "ADO.NET is a disconnected database architecture". Well, its true, but how? How can ADO is transformed to such an architecture which no other database architecture supports. Every other database programming supports only RecorsSet which you need to use to get Data from the database.  Did you ever thought of it ? If you don't, it is time to rethink of it now.

In this post, I will uncover few internals of ADO.NET architecture, and also refer to my favorite tool Reflector to see the code that is written inside the .NET classes. My focus in the post is only on the internals of the architecture, so if you  are new to ADO.NET, it would not be a good idea to read it over and confuse yourself more, rather read thorough Overview of ADO.NET and come back later.


Introduction

Well, In fact, I didn't ever thought of writing such a post. Strangely, while talking with Devs I found out people commenting that ADO.NET is a new way of accessing data missing out the point where ADO.NET differs with ADO. It is true, ADO.NET is disconnected. There are large performance gain of an application which releases the Connection after fetching data from the database. ADO.NET have inherent capability to release the database connection, after the so called DataSet / DataTable is filled with data which you might be looking for. There are few Adapters provided with .NET library which lets you Fill these DataSet or DataTable when you want and later you can use these cached data to your application.  Yes every line here is a fact. But internally there is still a Reader associated with every call. Let me detail the fact a little.


Details of Loading Data using Select Query

Say you invoke a Selection operation on the Database using Select Query. Lets jot down the steps what happens internally :