Revisiting

C#
Anoop Madhusudanan :
http://amazedsaint.com
This book is intended to be a value adding reading material
for beginner to intermediate C# programmers. It may also
be used for accelerating the learning about new and
upcoming features in C#, and also to get an introduction
about new libraries in .NET. You may find random articles
and alternate perspectives related to various aspects of C# -
ranging from delegates, lambdas, fluent interfaces, dynamic
features etc. with practical examples.
 Revisiting C# 1

Contents
Contents ........................................................................................................................................................ 1
Revisiting Delegates, Anonymous Methods and Lambdas ........................................................................... 2
Creating Fluent Interfaces In C#.................................................................................................................... 6
Anonymous Types in C# and Object Initializer Syntax ................................................................................ 10
Type Inference in Generic Methods ........................................................................................................... 12
The Case Of switch-case in C#..................................................................................................................... 13
C# 4.0 dynamic Features – Under the hood ............................................................................................... 15
Mr ExpandoObject in C# 4.0 ....................................................................................................................... 23
C# Enums – A Second Look ......................................................................................................................... 25
Top 5 Developer Mistakes C# Developers Should Not Commit.................................................................. 27
4 .NET 4.0 Libraries You Should Know About ............................................................................................. 31
Further Reading .......................................................................................................................................... 32
 Revisiting C# 2

Revisiting Delegates, Anonymous

Methods and Lambdas
Let us explore few concepts about Delegates, Anonymous methods, Lambdas and Expression Trees.
This is an introductory post, and I‟ll follow up with more posts. These code examples are pretty
simple, you can fire up a C# Console application in Visual Studio and try these examples if you are
interested.

Delegates
We know that a delegate is a type that can reference a method. For example, consider this example to
define a delegate and create a delegate instance.

1. //Example 1 - Creating a delegate instance using Named method

2.
3. public delegate int BinaryOperationDelegate(int x,int y);
4.
5. class Program
6. {
7. static void Main(string[] args)
8. {
9. //Create a delegate instance using named method
10. var add = new BinaryOperationDelegate(AddOperation);
11. int result = add(20, 30);
12. Console.WriteLine(result);
13. }
14.
15. static int AddOperation(int x,int y)
16. {
17. return x+y;
18. }
19. }

The above code will give you an output of 50, no doubt, right ? :)

Anonymous Methods
Now, you may know that with C# 2.0, we can use anonymous methods to create a delegate instance
without a named method. Let us re-write the above implementation leveraging an anon method.
Instead of the method name, you‟ve to use the „delegate‟ keyword. Also, note that there is no need to
specify a return type – because the return type will be inferred from the delegate signature.

1. //Example 2 - Creating a delegate instance using Anon method

2.
3. public delegate int BinaryOperationDelegate(int x,int y);
4.
5. class Program
6. {
7. static void Main(string[] args)
8. {
9. //Create a delegate instance using anon method
10. BinaryOperationDelegate add=
 Revisiting C# 3

11. delegate(int a, int b) { return a+b;} ;

12. int result = add(20, 30);
13. Console.WriteLine(result);
14. }
15.
16. }

Lambdas
And of course, you might also know that with C# 3.0, you can use Lambdas for producing anonymous
methods. A lamda expression is exactly a function, that can contain statements and expressions. Here
is the equivalent of above code, still shortened using a lambda

1.
2. //Example 3 - Creating a delegate instance using statement lambda
3.
4. public delegate int BinaryOperationDelegate(int x, int y);
5. class Program
6. {
7. static void Main(string[] args)
8. {
9. //Create a delegate instance using a statement lambda
10. BinaryOperationDelegate add =(a,b)=>{
11. //this statement block can contain
12. //multiple statements
13. return a+b;
14. };
15.
16. int result = add(20, 30);
17. Console.WriteLine(result);
18. }
19.
20.
21. }

In the above example, note the lambda syntax that replaces the anon method syntax in example 2

1. (a,b)=>{
2. return a+b;
3. };

The types of input parameters a and b and the return type will be inferred correctly by the compiler,
based on the context. How ever, on scenarios where the compiler can't infer the type directly, you can
provide that explicitly. Like this.
BinaryOperationDelegate add =(int a, int b)=>{ return a+b; };

There are basically two type of lambdas - Statement Lamdas and Expression Lambdas. The above
example shows a statement lambda, as the right hand expression is inside a statement block, of the
form

(param1, param2)=> { statement1; statement2; } ;

If you won't have input parameters, you may use the syntax
 Revisiting C# 4

()=> { statement1; statement2; } ;

=> simply means 'goes to', and you may say that the input parameters goes to the statements (for
some processing) :)

Statement Lambdas And Expression Lambdas

We‟ve seen how to create Statement lambdas in the above example. Now, let us explore a bit about
Expression Lambdas (or single line lambdas). The syntax is similar to statement lambdas, but for
expression lambdas, the right hand expression shouldnot be inside a statement block { }. Instead of
having statements on the right side, an Expression Lambda can have a single line expression on the
right hand side. Here is the simple example, with out the statement block.

1. public delegate int BinaryOperationDelegate(int x, int y);

2.
3. class Program
4. {
5. static void Main(string[] args)
6. {
7. //Expression Lambda
8. BinaryOperationDelegate add =(a, b)=>a+b;
9. int result = add(20, 30);
10.
11. Console.WriteLine(result);
12. }
13. }

The above code produces the same result as in the case of stament lambdas. How ever, Expression
lamdba has an advantage over statement lambda. When an expression lambda is assigned to a
variable of type Expression, the compiler emits code to build an expression tree that represents the
lambda expression, instead of a delegate instance.

1. //Example 4 - Expression Lambdas

2.
3. public delegate int BinaryOperationDelegate(int x, int y);
4.
5. class Program
6. {
7. static void Main(string[] args)
8. {
9. //Expression Lambda to delegate instance
10. BinaryOperationDelegate add =(a, b)=>a+b;
11. int result1 = add(20, 30);
12.
13. //Expression Lambda to Expression tree
14. Expression<BinaryOperationDelegate> addExpr = (a, b) => a + b;
15.
16. //Let us compile the expression tree before executing the same
17. var compiledAdd = addExpr.Compile();
18. int result2=compiledAdd(20,30);
19.
20.
21. Console.WriteLine(result1);
22. Console.WriteLine(result2);
23. }
24. }
 Revisiting C# 5

In the above example, you saw that we are assigning our expression lambda to the
System.Linq.Expression<TDelegate> to create an expression tree, and the compiling it to get the
actual delegate. Expression trees provide us a powerful way to represent code/logic as data, that can
be modified and/or interpreted at runtime if required.

Example Usages for Lambdas

These are some of the areas you may find using Lambdas pretty often.

To provide inline event handlers like

1. button.Click += (sender,args) =>

2. {
3. };

To find items in a collection

1. var dogs= animals.Where(animal => animal.Type == "dog");

For iterating a collection, like

1. animals.ForEach(animal=>Console.WriteLine(animal.Name));

Creating a custom object

1. var myObj= mySource.Select(x => new {Name = x.name, Age= x.age});

Simple one line methods

1. Func<int, int> add = x => x + x;

For aggregate operations

1. double charCount = document.Sum(word => word.Length)

 Revisiting C# 6

Creating Fluent Interfaces In C#

"FI(Fluent Interface) - when you use method chaining, after finishing the functionality, "return this",
and that's how you make it fluent".

This is a post about creating Fluent interfaces in C#, just to demonstrate various possibilities of Fluent
programming.

Chaining Methods - A Simple Scenario

Assuming that you are interested in training animals, let us start with a simple ITrainable interface. :)

1.
2. /// <summary>
3. /// Anything that is trainable
4. /// </summary>
5. public interface ITrainable
6. {
7. ITrainable Train(string skill);
8. ITrainable Do(string skill);
9. }

Well, nothing fancy there. Let us go ahead and create a Dog Class, which implements this interface.
The only interesting piece you may find in the Dog class is, all methods are returning a type of
ITrainable. As long as our Dog class implements ITrainable, we can return 'this', i.e the current Dog
Instance.

1. /// <summary>
2. /// Our simple dog class
3. /// </summary>
4. public class Dog : ITrainable
5. {
6. public string Name { get; set; }
7. public List<string> Skills { get; set; }
8.
9. public Dog(string name)
10. {
11. Console.WriteLine();
12. Console.WriteLine("Dog " + name +
13. " created");
14.
15. Name = name;
16. Skills = new List<string>();
17. }
18.
19. //Let us train this skill to our dog
20. //Note that we are returning 'this', so that
21. //we can continue training or ask the dog to perform
22. public ITrainable Train(string skill)
23. {
24. Console.WriteLine("Dog " + Name +
25. " learned " + skill);
26. this.Skills.Add(skill);
 Revisiting C# 7

27. return this;

28. }
29.
30. //Let us ask the dog to perform this skill
31. public ITrainable Do(string skill)
32. {
33. if (Skills.Contains(skill))
34. Console.WriteLine("Dog " + Name +
35. " is doing " + skill);
36. else
37. Console.WriteLine("Dog " + Name +
38. ": Don't know how to " + skill);
39.
40. return this;
41.
42. }
43. }

Now, we are ready to train our Dog fluently. Like,

1. //Train one dog, Hope your name is not Bobby ;)

2. var dog = new Dog("Bobby");
3. dog.Train("Running").Train("Eating")
4. .Do("Running").Do("Eating");

As you can see, we are chaining the method calls, because in each call, we are returning an object of
type ITrainable. You'll see what Bobby is doing in the console

Dog Bobby created

Dog Bobby learned Running
Dog Bobby learned Eating
Dog Bobby is doing Running
Dog Bobby is doing Eating

Chaining Methods - For Collections

Now, let us do something more interesting. Let us create a couple of extension methods for all
collections of ITrainable. We do this by writing an extension method for IEnumerable<ITrainable>. If
you see, our extension methods are accepting a bunch of trainable organisms(?) (read,
IEnumerable<ITrainable>) and returns the same.

Leave out the Console.WriteLine(), it is there just for some pretty printing.

1.
2.
3. /// <summary>
4. /// Let us fluently train a bunch of Trainable
5. /// animals
6. /// </summary>
7. public static class TrainableExtensions
 Revisiting C# 8

8. {
9. //Note that we are returning the IEnumerable<ITrainable>
10. public static IEnumerable<ITrainable>
11. Train(this IEnumerable<ITrainable> flock, string skill)
12. {
13. foreach (var member in flock)
14. member.Train(skill);
15. Console.WriteLine();
16. return flock;
17. }
18.
19. //Ask all members to perform a skill
20. public static IEnumerable<ITrainable>
21. Do(this IEnumerable<ITrainable> flock, string skill)
22. {
23. foreach (var member in flock)
24. member.Do(skill);
25. Console.WriteLine();
26. return flock;
27. }
28.
29. }

Now, let us create few dogs, and train them together :)

1. //Let us create the dogs and train them

2. var dogs = new List<ITrainable>{new Dog("Jimmy"),
3. new Dog("Sando"),
4. new Dog("Rob")};
5.
6. //Now train them
7. dogs.Train("EatingFood").Train("Running")
8. .Do("EatingFood")
9. .Train("JumpingToRing").Do("Running");

And you'll see what they are doing, in this order.

Dog Jimmy created

Dog Sando created
Dog Rob created

Dog Jimmy learned EatingFood

Dog Sando learned EatingFood
Dog Rob learned EatingFood

Dog Jimmy learned Running

Dog Sando learned Running
Dog Rob learned Running
 Revisiting C# 9

Dog Jimmy is doing EatingFood

Dog Sando is doing EatingFood
Dog Rob is doing EatingFood

Dog Jimmy learned JumpingToRing

Dog Sando learned JumpingToRing
Dog Rob learned JumpingToRing

Dog Jimmy is doing Running

Dog Sando is doing Running
Dog Rob is doing Running

Now, as LINQ methods are essentially extension methods on top of IEnumerable<T>, you can mix
and match the extension methods we just wrote, with LINQ methods. For example, if we decide only
Rob should learn a special skill (JumpingRing), you can do this.

1. dogs.Train("EatingFood").Skip(2)
2. .Train("JumpingRing").Union(dogs)
3. .Train("TakingPaper");

And you'll see how this works

Dog Jimmy learned EatingFood

Dog Sando learned EatingFood
Dog Rob learned EatingFood

Dog Rob learned JumpingRing

Dog Rob learned TakingPaper
Dog Jimmy learned TakingPaper
Dog Sando learned TakingPaper

And finally, Fluent APIs can be used for much more useful tasks (If you havn't yet realized, lol). Few
fluent API's I've come across

 Rhino Mocks
 ReadableRex
 Tweet#
 Revisiting C# 10

Anonymous Types in C# and Object

Initializer Syntax
This post is about the Anonymous types in C#, and the object initializer syntax.

It is well known that starting from C# 3.0, you can initialize an object like this.

1. var boy = new { Name = "Jim", Age = 2 };

You specify the properties of an object, and at compile time, the compiler will create a new
(anonymous) type, with the properties you specify, and with a constructor that can take the same
number of arguments. Now, let us examine our anonymous type in detail by using reflection. We'll
examine whether the type is a class, along with the type's name. If you run this,

1. static void Main(string[] args)

2. {
3.
4. var boy = new { Name = "Jim", Age = 2 };
5.
6. Console.WriteLine("Name=" + boy.GetType().Name);
7. Console.WriteLine("BaseType=" + boy.GetType().BaseType.Name);
8. Console.WriteLine("Asm=" + boy.GetType().Assembly.FullName);
9. Console.WriteLine("IsClass=" + boy.GetType().IsClass);
10. }

You'll get some output like

Name=<>f__AnonymousType0`2
BaseType=Object
Asm=AnonymousTest, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null
IsClass=True

Needless to say, the Name will be a random name, and the Assembly's name depends on your own
project name. The key point is, we just established that the type is there in the assembly - which
means, as I mentioned, the compiler created a type at compile time itself. You can have a look at the
IL if you are interested.

Now, let us examine the observation that the anonymous type has a constructor that takes the same
number of arguments as that of properties (i.e, in this case, the number of constructor arguments will
be equal to the number of properties we specified in the object initializer, of types string and int). We
can do that easily by creating a new instance of the anonymous type we have, using reflection. Add
this to the tail end of the last piece of code.

1. //These two calls will fail with a run time exception, Just keep them commented
2. //var newboy = Activator.CreateInstance(boy.GetType(), null);
3. //var newboy = Activator.CreateInstance(boy.GetType(), new object[] { "Joe"});
4.
5. //Only this will work. Creating a new boy
6. var newboy=Activator.CreateInstance(boy.GetType(),new object[]{"Joe",2});
 Revisiting C# 11

7.
8. //Just write back the name of new boy
9. Console.WriteLine(newboy.GetType().GetProperty("Name").GetValue(newobj, null));

You can see that only the last call will work, as we need to pass the same number of arguments while
instantiating. Note that you can have arrays of anonymous types as well, like this.

1. var guys = new[]

2. {
3. new {Name="Joe", Age=10},
4. new {Name="James", Age=22},
5. new {Name="Jim", Age=23},
6. new {Name="Jerard", Age=10},
7. };

Furthermore, I just want to mention one more point. You may not need to assign the property
explicitly, when you use the object initializer syntax. Consider this code.

1. var guy1 = new { Name = "Ken", Age = 30 };

2. var guy2 = new { guy1.Name, Age = 30 };
3.
4. Console.WriteLine(guy1.GetType().Name + " - " + guy1.Name);
5. Console.WriteLine(guy2.GetType().Name + " - " + guy2.Name);

The key point to note here is, for guy 2, we are not explicitly specifying the Name property. Instead,
we are just specifying that the name of Guy2 is same as Guy1. The compiler will assume the property
name from the given parameter's name (in fact, the last part of the specified parameter, in this case
'Name') - This is called Projection. Obviously, you'll find that both guy1 and guy2 are of the same type
as well.

Can you guess the output of this code as well?

1. string Name = "Guy2";

2.
3. var guy1 = new { Name = "Ken", Age = 30 };
4. var guy2 = new { Name, Age = 30 };
5.
6. Console.WriteLine(guy1.GetType().Name + " - " + guy1.Name);
7. Console.WriteLine(guy2.GetType().Name + " - " + guy2.Name);

Why anonymous types are interesting? Because we use them in various ways, especially while using
LINQ syntax. Here is a basic example

1. var oldGuys = from guy in guys

2. where guy.Age > 20
3. select new { guy.Name };

Here, you'll probably find that we are using projection in the select new block. And as the last pointer,
just debug and observe the type of oldGuys, and have a look at the base's type.
 Revisiting C# 12

Type Inference in Generic Methods

As you may already know, C# compiler doesn‟t support type inference for generic classes, but it
supports type inference for generic methods. To illustrate the point, let us consider a very simple
example.

1. class Program
2. {
3. //Our generic IsGreaterThan method
4. public static bool IsGreaterThan<T>(T x, T y) where T : IComparable<T>
5. {
6. return (x.CompareTo(y) > 0);
7. }
8.
9. static void Main(string[] args)
10. {
11. //You don't need to explicitly specify IsGreaterThan<int>
12. var result = IsGreaterThan(20,10);
13. Console.WriteLine(result);
14. }
15.
16. }

As you can see, we are not specifying the type explicitly, while calling our IsGreaterThan method - it is
inferred automatically by the compiler. That is simple, isn‟t it? Now, things become a a bit more
interesting when you combine Generic method type inference with extension methods. Have a look at
this code, we just made our IsGreaterThan<T> method an extension method.

1. public static class UtilExtensions

2. {
3. //Our generic IsGreaterThan extension method
4. public static bool IsGreaterThan<T>(this T x, T y) where T : IComparable<T>
5. {
6. return (x.CompareTo(y) > 0);
7. }
8. }
9.
10. class Program
11. {
12. static void Main(string[] args)
13. {
14. //You still don't need to explicitly specify IsGreaterThan<int>
15. var result = 20.IsGreaterThan(10);
16. Console.WriteLine(result);
17.
18. }
19.
20. }

As you can see, we are still good - the compiler can still infer the types. And of course, you can
leverage our IsGreaterThan against any IComparable implementation.
 Revisiting C# 13

The Case Of switch-case in C#.

In Javascript, most developers prefer creating a lean object that can be re-used, instead of a stubborn
switch case. For example, instead of this Switch Case implementation,

1. switch (foo) {
2. case 'case1':
3. alert('case1 code');
4. break;
5. case 'case2':
6. alert('case2 code');
7. break;
8. default:
9. alert('hm, default code');
10. break;
11. }

a number of developers may consider the below one as more elegant - because it is re-usable and
more testable.

1. var mySwitch= {
2. 'case1' : function() {
3. alert('case1 code');
4. },
5. 'case2' : function() {
6. alert('case2 code');
7. },
8. 'default' : function() {
9. alert('default code');
10. }
11. };
12.
13.
14. if (mySwitch[foo]) {
15. mySwitch[foo]();
16. } else {
17. mySwitch['default']();
18. }

I was thinking about implementing something along similiar lines in C#, to re-factor few fat switch
cases using a Dictionary. Obviously, this is context specific - one approach won't fit all the scenarios.
Here is a quick example to clarify the point.

1. public class SwitchCase : Dictionary<string,Action>

2. {
3. public void Eval(string key)
4. {
5. if (this.ContainsKey(key))
6. this[key]();
7. else
8. this["default"]();
9. }
10. }
11.
 Revisiting C# 14

12.
13. //Now, somewhere else
14.
15. var mySwitch = new SwitchCase
16. {
17. { "case1", ()=>Console.WriteLine("Case1 is executed") },
18. { "case2", ()=>Console.WriteLine("Case2 is executed") },
19. { "case3", ()=>Console.WriteLine("Case3 is executed") },
20. { "case4", ()=>Console.WriteLine("Case4 is executed") },
21. { "default",()=>Console.WriteLine("Default is executed") },
22. };
23.
24. mySwitch.Eval(c);

This provides loose coupling, and you can even modify the logic for each case easily using a setter or
so.
 Revisiting C# 15

C# 4.0 dynamic Features – Under the

hood
In this post, we‟ll go back to the basics to uncover few interesting aspects of C# 4.0 dynamic features.
Let us start with a simple experiment.
Static Typing or Early Binding

Let us start with a bare minimum program. Fire up VS2010 and try the following code.

It is obvious that this won‟t compile. Simply because, the compile/design time checking ensures type
safety - and as we don‟t have a method named SomeStupidCall in our Human class, we can‟t compile
the same.

So, that is what you get.

Duck Typing or Dynamic Typing or Late Binding
 Revisiting C# 16

Now, let us take a step back, and modify the above code like this. Change the type of variable h to
„dynamic‟. And Compile. Here is a little surprise!! You got it compiled!! By using „dynamic‟ keyword,
you just told the compiler, “dude, don’t bother if SomeStupidCall() is there in the Human type”

And now, run the application. The application will break for sure. But hey, that is your fault, not the
compiler‟s.

By the way, why we call dynamic typing as „Duck typing‟?

 Revisiting C# 17

Here we go, Quoted from Wikipedia

In duck typing, one is concerned with just those aspects of an object that are used, rather than with
the type of the object itself. For example, in a non-duck-typed language, one can create a function
that takes an object of type Duck and calls that object's walk and quack methods. In a duck-typed
language, the equivalent function would take an object of any type and call that object's walk and
quack methods. If the object does not have the methods that are called then the function signals a
run-time error. It is this action of any object having the correct walk and quack methods being
accepted by the function that evokes the quotation and hence the name of this form of typing.

Now, why you need ‘dynamic’ at all?

I hope the above scenario is „good‟ enough to give you an „evil‟ impression about the dynamic
features. But, wait. There are lot of scenarios where the dynamic features can really simplify things for
you. For example, let us assume a reflection based scenario, where you load a type (from an external
assembly or so), to invoke a member. Here is a quick example. You‟ll see how to use dynamic as an
easier alternative for reflection. This is much more evident when you deal with scenarios like COM
interop etc. We‟ll see more interesting uses later.
 Revisiting C# 18

How a ‘dynamic’ type is getting compiled?

Let us get back to a basic example. Consider a human class, with a Walk() method and Age property.
Now, let us create a new Human and assign this to a dynamic variable „h‟.
 Revisiting C# 19

Let us build the above application. Fire up Reflector, open the binary executable of the app, and have
a look at the same. With a bit of cleanup, this is the relevant part of the disassembled code - which is
the equivalent 'statically‟ typed code generated by the compiler, for the „dynamic‟ code we wrote
above.

You‟ll see a „SiteContainer‟, for keeping track of the context, and two call site fields.

And here is the disassembled code for the member invocations. It might be interesting to note that,
the variable „h‟ is compiled as a simple CLR „object‟. Wow, from the CLR point of few, there is nothing
like a „dynamic‟ type. Instead, all member invocations to our „dynamic‟ object are modified; in such a
way that they are piped through a dynamic Call Site. The Call Site is initialized with the Binder
responsible for run time binding. In this case, you may note that the C# run time binder will be used
to invoke the members(Microsoft.CSharp.RuntimeBinder.Binder „s InvokeMember will return a CallSite
binder, that‟ll be used by the Call Site).
 Revisiting C# 20

You might be thinking how the code will be generated for scenarios where, you have a method that
accepts or returns a „dynamic‟ type, or a property that gets or sets a dynamic type. Let us try this out.
Change our above Human class in the above example, to something like this. Note that now Walk
method accepts a dynamic type, and Age property is also modified to get/set dynamic types.
 Revisiting C# 21

Have a sneak peak using Reflector. You‟ll note that, the compiler has generated a special [Dynamic]
attribute to the input parameter of Walk() method. Also, the getter and setter of the Age property is
also decorated with the [Dynamic] attribute, as shown below.

Conclusion

And here is some code of the final form of our experiment. Create a Console app in C# 4.0, to play
with this.

1. using System;
2. using System.Collections.Generic;
3. using System.Linq;
4. using System.Text;
5. using System.Runtime.CompilerServices;
6. using Microsoft.CSharp.RuntimeBinder;
7.
8. namespace DynamicTest
9. {
10. class Human
11. {
12. public void Walk(dynamic place)
13. {
14. Console.WriteLine("I'm walking to " + place);
15. }
16. public dynamic Age { get; set; }
17. }
18.
19. class Program
20. {
21. // Methods
22. private static void Main(string[] args)
23. {
 Revisiting C# 22

24. //dynamic h = new Human();

25. //h.Walk("Paris");
26. //h.Age = 10;
27.
28. //will get compiled to
29.
30. object h = new Human();
31.
32. //Create the site 1 if it is null
33. if (SiteContainer0.Site1 == null)
34. {
35. SiteContainer0.Site1 = CallSite<Action<CallSite, object, string>>.Create
36. (Binder.InvokeMember(CSharpBinderFlags.ResultDiscarded, "Walk",
37. null, typeof(Program), new CSharpArgumentInfo[]
38. { CSharpArgumentInfo.Create(CSharpArgumentInfoFlags.None, null),
39. CSharpArgumentInfo.Create(CSharpArgumentInfoFlags.LiteralConstant
40. | CSharpArgumentInfoFlags.UseCompileTimeType, null) }));
41. }
42. SiteContainer0.Site1.Target(SiteContainer0.Site1, h, "Paris");
43.
44. //Create the site 2 if it is null
45. if (SiteContainer0.Site2 == null)
46. {
47. SiteContainer0.Site2 = CallSite<Func<CallSite, object, int, object>>.Create

48. (Binder.SetMember(CSharpBinderFlags.None, "Age", typeof(Program),

49. new CSharpArgumentInfo[]
50. { CSharpArgumentInfo.Create(CSharpArgumentInfoFlags.None, null),
51. CSharpArgumentInfo.Create(CSharpArgumentInfoFlags.LiteralConstant |

52. CSharpArgumentInfoFlags.UseCompileTimeType, null) }));

53. }
54. SiteContainer0.Site2.Target(SiteContainer0.Site2, h, 10);
55. }
56.
57.
58. // Nested Types
59. [CompilerGenerated]
60. private static class SiteContainer0
61. {
62. // Fields
63. public static CallSite<Action<CallSite, object, string>> Site1;
64. public static CallSite<Func<CallSite, object, int, object>> Site2;
65. }
66.
67. }
68.
69. }
 Revisiting C# 23

Mr ExpandoObject in C# 4.0
.NET framework 4.0 has a cool new ExpandoObject class, in System.Dynamic namespace. What
makes this special is, it allows you to create an object with members that can be dynamically added
and removed at run time.

To clarify the point, have a look at this example.

1. dynamic obj = new ExpandoObject();

2. obj.Value = 10;
3. var action = new Action<string >((line) => Console.WriteLine(line));
4. obj.WriteNow = action;
5. obj.WriteNow(obj.Value.ToString());

And you'll get 10 as output in your console. As you can see, the property 'Value' and method
'WriteNow' is attached at runtime, when the invocation happens.

The objective of this post is to examine how the ExpandoObject itself is implemented. To make this
clear, let us create a MyExpando class, a minimal implementation of ExpandoObject.

We are inheriting MyExpando class from the DynamicObject, and these are the major methods we are
overriding.

 TrySetMember- Provides the implementation of setting a member.

 TryGetMember-Provides the implementation of getting a member.
 TryInvokeMember- Provides the implementation of calling a member.
 GetDynamicMemberNames- Returns the enumeration of all dynamic member names.

And Here is our minimal MyExpando class, inherited from DynamicObject, and overrides the above
methods.

1. public class MyExpando : DynamicObject

2. {
3.
4. private Dictionary < string, object > _members = new Dictionary < string, object
> ();
5.
6.
7. /// <summary>
8. /// When a new property is set, add the property name and value to the dictionary

9. /// </summary>
10. public override bool TrySetMember(SetMemberBinder binder, object value)
11. {
12. if (!_members.ContainsKey(binder.Name))
13. _members.Add(binder.Name, value);
14. else
15. _members[binder.Name] = value;
16.
17. return true;
18. }
19.
 Revisiting C# 24

20. /// <summary>

21. /// When user accesses something, return the value if we have it
22. /// </summary>
23. public override bool TryGetMember(GetMemberBinder binder, out object result)
24. {
25. if (_members.ContainsKey(binder.Name))
26. {
27. result = _members[binder.Name];
28. return true;
29. }
30. else
31. {
32. return base.TryGetMember(binder, out result);
33. }
34. }
35.
36. /// <summary>
37. /// If a property value is a delegate, invoke it
38. /// </summary>
39. public override bool TryInvokeMember(InvokeMemberBinder binder, object[] args, ou
t object result)
40. {
41. if (_members.ContainsKey(binder.Name) && _members[binder.Name] is Delegate)
42. {
43. result = (_members[binder.Name] as Delegate).DynamicInvoke(args);
44. return true;
45. }
46. else
47. {
48. return base.TryInvokeMember(binder, args, out result);
49. }
50. }
51.
52.
53. /// <summary>
54. /// Return all dynamic member names
55. /// </summary>
56. /// <returns></returns>
57. public override IEnumerable&ltstring> GetDynamicMemberNames()
58. {
59. return _members.Keys;
60. }
61. }

Whenever a property set operation happens, the runtime will invoke TrySetMember, and there, we are
pushing the property name and value to a dictionary. Similarly, whenever a get operation happens
(TryGetMember), we are simply returning the value object if available in the dictionary. Also, when a
method call is made (TryInvokeMember), if the value type is a delegate, we just invoke the same by
passing the arguments we received. Pretty simple, huh? Well, that is it. Now, let us try the above
scenario with our MyExpando object

1. dynamic obj = new MyExpando();

2. obj.Value = 10;
3. var action = new Action<string>((line) => Console.WriteLine(line));
4. obj.WriteNow = action;
5. obj.WriteNow(obj.Value.ToString());

Run the application, and guess what you get!!

 Revisiting C# 25

C# Enums – A Second Look

Consider the following code, where you accept a caller key and a token request from a caller, to issue
a security key for further requests? Note that we also have a minimal exclusion check, where we
prevent certain callers from getting the admin permission. Now, the question. What is wrong with the
code below?

1. public enum SecurityToken

2. {
3. Admin,
4. Registered,
5. Anon
6. }
7.
8. public class SecurityGateway
9. {
10. public string GetSecurityKey(string callerKey,SecurityToken token)
11. {
12.
13. //Prevent caller2 from getting the admin token
14. if (callerKey.Equals("secretcallerkey2")
15. && token == SecurityToken.Admin)
16. return "Error: You can't request an admin token";
17.
18. //Issue the token
19. switch (token)
20. {
21. case SecurityToken.Anon:
22. return "PermissionKeyForAnonymous";
23. case SecurityToken.Registered:
24. return "PermissionKeyForRegistered";
25. default:
26. return "PermissionKeyForAdmin";
27. }
28. }
29. }

If you already found the issue, you may stop reading here. Otherwise, let us examine this in a bit
detail.

Assume that a caller, let us sayCaller1, is requesting a security key for leveraging admin permissions.

1. SecurityGateway gateway = new SecurityGateway();

2.
3. //Caller 1
4. var key = gateway.GetSecurityKey("secretcallerkey1", SecurityToken.Admin);

5. //key's value is PermissionKeyForAdmin for secretcallerkey1

As you may imagine, the value of key will be PermissionKeyForAdmin, as expected.

 Revisiting C# 26

Now, the issue. As you may be aware, C# enums are implemented as integers by default, and you can
cast integers to an enum type. So, if the Caller2 has some evil plans, it may do something like this.

1. SecurityGateway gateway = new SecurityGateway();

2.
3. //Caller 2
4. var key = gateway.GetSecurityKey("secretcallerkey2", (SecurityToken)10);
5.
6. //OOps, key's value is still PermissionKeyForAdmin for secretcallerkey2,
7. //bypassing the exclusion check we've above
8.

Note that I'm casting an integer to an enum, and the following exclusion check will be bypassed by
Caller2, because the token's value is 10, instead of the value for SecurityToken.Admin.

1. //OOps, Caller2 can bypass this exclusion check

2.
3. //Prevent caller2 from getting the admin token
4. if (callerKey.Equals("secretcallerkey2")
5. && token == SecurityToken.Admin)
6. return "Error: You can't request an admin token";

Alright, so the point is, be a bit more careful when working with Enums in general, and also when you
implement check conditions with enums.

Now, there is a better solution - An explicit check using Enum.IsDefined(..) to validate if the passed
value exists in the specified enumeration is the best solution.
 Revisiting C# 27

Top 5 Developer Mistakes C# Developers

Should Not Commit
Some time back, I asked a question in Stackoverflow.com, about common programming mistakes
.NET developers must avoid. The response was awesome, to say the least. I‟m just listing down the
top 5 developer crimes I picked, from the answers I received (regardless the votes).

1. Breaking the stack unnecessarily when you re-throw an exception

This a pretty „old thing‟ - but surprisingly, still a very common mistake.

As TheSoftwareJedi mentioned, you don‟t really need to break the stack while throwing exceptions.
I‟ve done this myself when I was a beginner - and I‟ve seen this more often than anything else when I
do code reviews these days.

To clarify the point - What is the difference between

try { ..} catch (Exception ex) { throw ex; }

and
try {..} catch(Exception ex) { throw; } ?

And when you lose the stack trace, you can‟t debug your app – and even worse, you can‟t log your
error details properly to your error log.

The MSDN guidelines on exception handling clearly states

 Revisiting C# 28

Do not rethrow by throwing the same exception object. This causes the stack trace for the original
exception to be lost--use a lone "throw;" statement (without an object following it) to "rethrow" a
catch exception.

2. Not using using to dispose objects

When ever you initialize an IDisposable object, it is a good practice to initiate it in a using statement
to ensure the object is getting disposed properly, like this.

Most developers won‟t do that. Greg Dean pointed the same.

Here is a little bit of re-cap from MSDN

As a rule, when you use an IDisposable object, you should declare and instantiate it in a using
statement. The using statement calls the Dispose method on the object in the correct way, and it
also causes the object itself to go out of scope as soon asDispose is called. Within the usingblock, the
object is read-only and cannot be modified or reassigned.
The using statement ensures that Dispose is called even if an exception occurs while you are calling
methods on the object. You can achieve the same result by putting the object inside a try block and
then calling Dispose in a finally block; in fact, this is how the using statement is translated by the
compiler.

Also, do you know that a using statement is expanded by the compiler to a try{..} finally{..} block at
compile time? Read more tips about using statement in MSDN.

3. Not unhooking event handlers appropriately after wiring them.

I think Scott Langham brought up a great point about not unhooking event handlers. People don‟t
really „remember‟ to unhook events.
 Revisiting C# 29

In C#, when you register an event handler, you are creating a strong reference from the event source
to the listener. So, the listener won‟t get garbage collected even if you don‟t have any pointers to the
listener - unless you unhook the event by yourself, and this might even result in a memory leak.
So, if you are thinking about how to deal with situations where your Source is having a longer life
span than the listener – there are multiple ways to deal with it, and Daniel Grunwald covers them
nicely in this excellent Codeproject Post.

4. Forgetting that Strings are immutable

In .NET, we know that strings are immutable – which means, once a string is created, its value can‟t
be changed. All string operations you perform, actually returns a new string containing the
modification.
John Sonmez have a nice point with an example.

5. Not Overriding GetHashCode when overriding Equals method in C#

Why this is important? If Hashcode of two items does not match, they‟ll be never considered equal,
and the Equals method will never be called to execute your custom comparison logic – let us say, in
scenarios where your objects are used as a key in a dictionary or so. Hence, in first place, you should
 Revisiting C# 30

override GetHashCode and return the same value for two equal objects based on comparison logic.
I‟ve seen this a couple of times during code review.
So, though Mark Gravell has several interesting points in his answer, my pick is about not overriding
GetHashCode when you override Equals method in C#.
 Revisiting C# 31

4 .NET 4.0 Libraries You Should Know

About
In this post, I‟ll consolidate few posts on four .NET libraries/frameworks, that‟ll help you write better
apps

MEF or Managed Extensibility Framework -

System.ComponentModel.Composition
MEF or Managed Extensibility Framework is cool. Firstly, it allows you to decouple your components
pretty easily. Secondly, it supports various component discovery scenarios, and enables you to write
better frameworks.
 An Introduction to MEF- Creating a Zoo And Animals
 MEF or Managed Extensibility Framework and Lazy<T> – Being Lazy with MEF, Export Attributes
etc

Reactive Extensions and LINQ To Events – System.Reactive

Reactive Extensions will soon become the de-facto for writing asynchronous code in a declarative
manner .NET Rx gives greater freedom to compose new events – you can create specific events out of
general events
 What is LINQ To Events
 Concepts And First Look
 Linq To Events – A WPF Drawing Demo
 A Text Template for generating GetEventName wrapper

Parallel Extensions and Tasks – System.Threading.Tasks

With those multi core processors everywhere, support for parallelism is an already implicit
requirement for any new application. NET 4.0 framework provides a wealth of easy to use primitives
and abstractions to enable developers to quickly write parallel programs, targeting multi core
machines.
 An Introduction to Tasks in Parallel Extensions

Dynamic Extensions – System.Dynamic

C# 4.0 introduced dynamic capabilities (duck typing) capabilities. There are a number of scenarios
where the dynamic features can really simplify things for you. For example, let us assume a Reflection
based scenario where you load a type (from an external assembly or so) to invoke a member, or think
about a dynamic fluent wrapper on top of XML or JSON.
 An introduction to C# 4.0 dynamic keyword
 Understanding ExpandoObject in .NET 4.0
 A Dynamic Wrapper in .NET 4.0
 Revisiting C# 32

Further Reading
Also, check out my EBook on Design patterns here

 Published Software Design Patterns For Everyone Ebook

On the C# side, here are few more interesting reads for you.

 7 Freely Available Ebooks For .NET developers

 Top 7 Coding Standards & Guideline Documents For C#/.NET Developers
 5 Back to Basics C# Articles - Fluent Interfaces, Expr Trees etc
 3 Gems from Mono to spice up your .NET Apps
 Top 5 Common Mistakes .NET Developers Must Avoid
 6 Cool VS2010 Tips you may find interesting
 4 .NET 4.0 Libraries you *should* know about