Let’s take a quick look at the object keyword first. I’m not going to talk a lot about it because it’s been around since C# 1.0. This keyword is nothing more than a shortcut for System.Object, which is the root type in the C# class hierarchy. (However, as Eric Lippert pointed out in his blog post, not everything in C# derives from object.) This is a powerful mechanism, since you can assign almost any value to instances of this type.

Here is a short example that demonstrates some of the benefits and problems of using the object keyword.

As you can see, although obj stores an integer, the compiler does not let you to perform any mathematical operations without a cast. It may look like casting helps you to ensure that you really have an integer, but it doesn’t. You can cast to a completely different type and the compiler will not detect it. As a result, you get a run-time exception.

So you have to perform an explicit cast that does not guarantee anything just because the compiler doesn’t let you to run your program without a cast.

Here is where the new dynamic keyword in C# 4.0 comes in. It tells the compiler not to enforce additional rules upon your code.

This is one of the main differences between object and dynamic – with dynamic you tell the compiler that the type of an object can be known only at run time, and the compiler doesn’t try to interfere. As a result, you can write less code. And I want to emphasize that this is no more dangerous than using the original object keyword. However, it is not less dangerous either, so all the type-checking techniques that you need to use when operating with objects (such as reflection) have to be used for dynamic objects as well.

The next question that often comes up is something like the following: “Since a dynamic object can be anything and the compiler doesn’t check what it is, does it mean that you can pass a dynamic object to my unsuspecting method/system and make it crash?”

Let’s assume we have a simple method.

Now let’s look at how you can pass a dynamic object to it.

As you can see, although the compiler allows you to pass a dynamic object to your method, your method never gets this object if it has a wrong type. An exception is thrown before the method is actually called. The only way you can pass a dynamic object to your method is if it contains a necessary value, in this case, a string.

Again, this is not that much different from the behavior you get with the object keyword.

Starting with C# 3.0 and Visual Studio 2008, you can use expression trees to get information about objects, types, and members. In this post I’m going to show some examples and explain what benefits you can get by using this technique. If you are not familiar with expression trees, I would recommend reading Charlie Calvert’s blog post Expression Tree Basics first.

Let’s start with a simple task. Assume that you want to print the name of a field or a property next to its value. For example, imagine that you have the following class.

Of course, there is a straightforward solution:

The problem with the above code is that you use a string literal SomeField. Nothing guarantees that this is the real name of the field. You might type the name incorrectly or just accidentally specify the wrong name. Furthermore, if you rename your property to, say, AnotherField, it could be hard to find a string literal that represents its name.

Here is how you can create a method that returns a property name by using expression trees, without using any string literals:

To call this method, you need to give it a lambda expression, as shown below.

Because of the lambda expression, you get not only compile-time error checking, but also full IntelliSense support when typing a member name. And if you rename a property, the compiler will find all the places where the property name is used. Or you can rely on refactoring tools to rename all the instances of the property for you.

In fact, you can also use this method to get the name of the variable itself (which can be convenient for tracing and logging).

The only problem with using a lambda expression is that you need to ensure that the user passes the correct one. For example, the user of your method can pass a lambda expression like () => new SampleClass(). Unfortunately, you can’t get a compile check for this. So, when using a lambda expression, make sure that you really get the expression you expect. For example, like this:

One more scenario where expression trees can help you is getting information about members of a type. C# provides the typeof operator to get type information, but does not provide operators like memberof or infoof. You can use reflection methods such as Type.GetField(), Type.GetMethod(), and so on, but then you have to use string literals again.

The problem gets worse if you have overloaded methods in your class.

In this case, you need to specify a method and also its parameters.

Now you have more ways to get yourself into trouble. In addition to explicitly specifying the name of your method, you’ve also specified the number and types of its parameters. So any changes in the method signature can affect the behavior of your program, and the compiler will not detect it.

With expression trees you can get the same information without using string literals, and also get the compiler to check whether the member you need exists. Furthermore, all you need to do to get a necessary method overload is provide an example of the method usage within a lambda expression. Thanks to Mads Torgersen, a Visual Studio Program Manager, for providing the following code example.

Now you can use the MemberOf method for all kinds of scenarios, for both instance and static members.

I want to repeat that this functionality is already available in C# 3.0 and .NET Framework 3.5. If you want to know how expression trees are extended in .NET Framework 4, take a look at one of my previous posts: Generating Dynamic Methods with Expression Trees in Visual Studio 2010.

First of all, let’s take a look at the example from one of my previous posts. It creates an expression tree for calculating the factorial of a number.

ParameterExpression value = 
    Expression.Parameter(typeof(int), "value");
ParameterExpression result = 
    Expression.Parameter(typeof(int), "result");
LabelTarget label = Expression.Label(typeof(int));
BlockExpression block = Expression.Block(
    new[] { result },
    Expression.Assign(result, Expression.Constant(1)),
    Expression.Loop(
        Expression.IfThenElse(
            Expression.GreaterThan(value, 
                Expression.Constant(1)),
            Expression.MultiplyAssign(result,
                Expression.PostDecrementAssign(value)),
        Expression.Break(label, result)
        ),
        label
    )
);
Expression<Func<int, int>> lambda = 
    Expression.Lambda<Func<int, int>>(block, value);
Console.WriteLine(lambda.Compile()(5));

Now, what if you want to see the content of this tree in debug mode? You can try lambda.ToString() but it’s not very informative. All you get is this: value => {var result; … }. Basically, it tells you only that the lambda has the result parameter.

Another option is to explore the tree structure in the Watch window. However, since this is a tree, you need to click through numerous nodes. This gives you a good understanding of the tree structure, but it might be hard to understand the actual content of the tree.

But there is a better solution: expression trees now have their own visualizer that helps you to explore their structure and content.

Copy the above code example into Visual Studio 2010, set a breakpoint at the last line, and press F5. Rest the mouse pointer over the lambda variable and you will see that it has the DebugView property. This property is private and is exposed only in the debugger, so you can’t use it in your code. But it’s used to hook up the expression trees visualizer. Click the magnifying glass icon and you will see the list of available visualizers.

Now click Text Visualizer and you get this.

As you can see, the content of the expression tree is represented in some kind of metalanguage. (No, we couldn't use C# here, because expression trees serve other languages as well.)

There are some simple rules used in this metalanguage:

• Parameters are displayed with a $ symbol at the beginning (for example, $result and $value.)
• Integer, string, and null constants are displayed “as is” (for example, $result = 1). For other numeric types that have standard suffixes, the suffix is added to the value. (For example, for decimal the value is 1M, for double 1D, etc.)
• If a parameter, label, or lambda expression does not have a name, the name is generated automatically (for example, #Label1, $var1, etc.)
• Checked operators are displayed with the # symbol preceding the operator. For example, the checked addition operator is displayed as #+.

There are some other nuances that I think are evident and don't need additional explanation. But if you don’t understand something in this syntax, let me know and I'll include more information in the documentation.

In the previous post I showed how you can use the new dynamic feature and the ExpandoObject class to add and remove properties at run time, and how this can make your code more readable and flexible than code written with LINQ to XML syntax.

But there were some obvious flaws in that example: While ExpandoObject provided better syntax, LINQ to XML provided a lot of useful library methods that helped you to work with XML files. So, is it possible to combine those two advantages, to have better syntax and still get all those methods? The answer is yes, but you need another type from the System.Dynamic namespace: DynamicObject.

The DynamicObject class enables you to override operations like getting or setting a member, calling a method, or performing any binary, unary, or type conversion operation. To illustrate the issue, let’s create a very simple object that overrides the “get property” operation, so that whenever you access a property it returns the property’s name as a string. This example has no practical value.

public class SampleObject : DynamicObject
{
    public override bool TryGetMember(
        GetMemberBinder binder, out object result)
    {
        result = binder.Name;
        return true;
    }
}

As with ExpandoObject, we must use the dynamic keyword to create an instance of this class.

dynamic obj = new SampleObject();
Console.WriteLine(obj.SampleProperty);
//Prints "SampleProperty".

Let’s see what’s going on in this example. When you call obj.SampleProperty, the dynamic language runtime (DLR) uses the language binder to look for a static definition of this property in the SampleObject class. If there is no such property, the DLR calls the TryGetMember method. This method gets information about what property it was called for through the binder parameter. As you can see, the binder.Name contains the actual name of the property.

The TryGetMember method returns true if the operation is successful. But the actual result of the operation must be assigned to the out parameter result. In this example, TryGetMember returns true, but obj.SampleProperty returns "SampleProperty".

Now let’s move to a more complex example and create a wrapper for the XElement object. Once again, I’ll try to provide better syntax for the following LINQ to XML sample.

XElement contactXML =
    new XElement("Contact",
    new XElement("Name", "Patrick Hines"),
    new XElement("Phone", "206-555-0144"),
    new XElement("Address",
        new XElement("Street1", "123 Main St"),
        new XElement("City", "Mercer Island"),
        new XElement("State", "WA"),
        new XElement("Postal", "68042")
    )
);

First of all, I need to create an analog of ExpandoObject. I still want to be able to dynamically add and remove properties. But since I am essentially creating a wrapper for the XElement type, I’ll use XElement instead of the dictionary to maintain the properties.

public class DynamicXMLNode : DynamicObject
{
    XElement node;
    public DynamicXMLNode(XElement node)
    {
        this.node = node;
    }
    public DynamicXMLNode()
    {
    }
    public DynamicXMLNode(String name)
    {
        node = new XElement(name);
    }
    public override bool TrySetMember(
        SetMemberBinder binder, object value)
    {
        XElement setNode = node.Element(binder.Name);
        if (setNode != null)
            setNode.SetValue(value);
        else
        {
            if (value.GetType() == typeof(DynamicXMLNode))
                node.Add(new XElement(binder.Name));
            else
                node.Add(new XElement(binder.Name, value));
        }
        return true;
    }
    public override bool TryGetMember(
        GetMemberBinder binder, out object result)
    {
        XElement getNode = node.Element(binder.Name);
        if (getNode != null)
        {
            result = new DynamicXMLNode(getNode);
            return true;
        }
        else
        {
            result = null;
            return false;
        }
    }
}

And here is how you can use this class.

dynamic contact = new DynamicXMLNode("Contacts");
contact.Name = "Patrick Hines";
contact.Phone = "206-555-0144";
contact.Address = new DynamicXMLNode();
contact.Address.Street = "123 Main St";
contact.Address.City = "Mercer Island";
contact.Address.State = "WA";
contact.Address.Postal = "68402";

Let’s look at the contact object. When this object is created, it initializes its inner XElement. If you set a property value, like in contact.Phone = "206-555-0144", the TrySetMember method checks whether an element with the name Phone exists in its XElement. If it does not exist, the method creates the element.

The next interesting line is contact.Address = new DynamicXMLNode(). Basically, in this particular example this line means that I want to create a node that has subnodes. For this property, the TrySetMember method creates an XElement without a value.

The most complex case here is a line such as contact.Address.State = "WA". First, the TryGetMember method is called for contact.Address and returns a new DynamicXMLNode object, which is initialized by the XElement with the name Address. (Theoretically, I could have returned the XElement itself, but that would make the example more complicated.) Then the TrySetMember method is called. The method looks for the State element in contact.Address. If it doesn’t find one, it creates it.

So I have successfully created the required XML structure. But TryGetMember always returns an instance of DynamicXMLNode. How do I get the actual value of the XML node? For example, I want the following line to work, but now it throws an exception.

String state = contact.Address.State;

I have several options here. I can modify the TryGetMember method to return actual values for leaf nodes, for example. But let’s explore another option: override type conversion. Just add the following method to the DynamicXMLNode class.

public override bool TryConvert(
    ConvertBinder binder, out object result)
{
    if (binder.Type == typeof(String))
    {
        result = node.Value;
        return true;
    }
    else
    {
        result = null;
        return false;
    }
}

Now whenever I have an explicit or implicit type conversion of the DynamicXMLNode type, the TryConvert method is called. The method checks what type the object is converted to and, if this type is String, the method returns the value of the inner XElement. Otherwise, it returns false, which means that the language should determine what to do next (in most cases it means that you’re going to get a run-time exception).

The last thing I’m going to show is how to get access to the XElement methods. Let’s override the TryInvokeMember method so that it will redirect all the method calls to its XElement object. Of course, I’m using the System.Reflection namespace here.

public override bool TryInvokeMember(
    InvokeMemberBinder binder, 
    object[] args, 
    out object result)
{
    Type xmlType = typeof(XElement);
    try
    {
        result = xmlType.InvokeMember(
                  binder.Name,
                  BindingFlags.InvokeMethod |
                  BindingFlags.Public |
                  BindingFlags.Instance,
                  null, node, args);
        return true;
    }
    catch
    {
        result = null;
        return false;
    }
}

This method enables you to call XElement methods on any node of the DynamicXMLNode object. The most obvious drawback here is absence of IntelliSense.

I’m not even going to pretend that this example is a ready-to-use wrapper for the LINQ to XML library. It doesn’t support attributes, doesn’t allow you to create a collection of nodes (for example, multiple contacts), and it is probably missing other features. Creating a library is a difficult task, and creating a good wrapper is too. But I hope that after reading this blog post you can create a fully functioning wrapper with DynamicObject yourself.

So, if you routinely use a library with complicated syntax that crawls XML files or works with script objects, or if you are creating such a library yourself, you should probably consider writing a wrapper. Doing this might make you more productive and the syntax of your library much better.

All the examples provided in this blog post work in the just released Visual Studio 2010 Beta 2. If you have any comments or suggestions, you are welcome to post them here or contact the DLR team at http://www.codeplex.com/dlr. You can also send an e-mail to the DLR team at dlr@microsoft.com.

Documentation for DynamicObject is also available on MSDN (check out our new MSDN design and don’t forget to take a look at the lightweight view.) In documentation, you can read about other useful methods of this class, such as TryBinaryOperation, TryUnaryOperation, TrySetIndex, and TryGetIndex.

You have probably already heard about the new dynamic feature in C# 4.0 and how it is used to support COM interop. If you haven't, I strongly recommend reading the following MSDN articles: Using Type dynamic and How to: Access Office Interop Objects by Using Visual C# 2010 Features.

Well, where else can you use this new feature? What are the use cases? Where does dynamic dispatch work better than static typing?

The quick answer is that whenever you see syntax like myobject.GetProperty("Address"), you have a use case for dynamic objects. First of all, the above syntax is difficult to read. Second, you don’t have any IntelliSense support for the property name, and if the “Address” property doesn’t exist you get a run-time exception. So why not create a dynamic object that calls the property as myobject.Address? You still get the run-time exception, and you still don't get IntelliSense, but at least the syntax is much better.

In fact, it’s not just better syntax. You also get flexibility. To demonstrate this flexibility, let’s move to ExpandoObject, which is a part of the new dynamic language runtime (DLR). ExpandoObject instances can add and remove members at run time. Where can you use such an object? XML is a good candidate here.

Here’s a code example that I took from MSDN. (Yes, I am an MSDN writer myself, so I use MSDN a lot.)

XElement contactXML =
    new XElement("Contact",
        new XElement("Name", "Patrick Hines"),
        new XElement("Phone", "206-555-0144"),
        new XElement("Address",
            new XElement("Street1", "123 Main St"),
            new XElement("City", "Mercer Island"),
            new XElement("State", "WA"),
            new XElement("Postal", "68042")
        )
    );

Although LINQ to XML is a good technology and I really love it, those new XElement parts look a little bit annoying. This is how I can rewrite it by using ExpandoObject.

dynamic contact = new ExpandoObject();
contact.Name = "Patrick Hines";
contact.Phone = "206-555-0144";
contact.Address = new ExpandoObject();
contact.Address.Street = "123 Main St";
contact.Address.City = "Mercer Island";
contact.Address.State = "WA";
contact.Address.Postal = "68402";

Just note a couple of things. First, look at the declaration of contact.

dynamic contact = new ExpandoObject();

I didn’t write ExpandoObject contact = new ExpandoObject(), because if I did contact would be a statically-typed object of the ExpandoObject type. And of course, statically-typed variables cannot add members at run time. So I used the new dynamic keyword instead of a type declaration, and since ExpandoObject supports dynamic operations, the code works.

Second, notice that every time I needed a node to have subnodes, I simply created a new instance of ExpandoObject as a member of the contact object.

It looks like the ExpandoObject example has more code, but it’s actually easier to read. You can clearly see what subnodes each node contains, and you don’t need to deal with the parentheses and indentation. But the best part is how you can access the elements now.

This is the code you need to print the State field in LINQ to XML.

Console.WriteLine((string)contactXML.Element("Address").Element("State"));

And this is how it looks with ExpandoObject.

Console.WriteLine(contact.Address.State);

But what if you want to have several Contact nodes? Like in the following LINQ to XML example.

XElement contactsXML =
    new XElement("Contacts",
        new XElement("Contact",
            new XElement("Name", "Patrick Hines"),
            new XElement("Phone", "206-555-0144")
        ),
        new XElement("Contact",
            new XElement("Name", "Ellen Adams"),
            new XElement("Phone", "206-555-0155")
        )
    );

Just use a collection of dynamic objects.

dynamic contacts = new List<dynamic>();

contacts.Add(new ExpandoObject());
contacts[0].Name = "Patrick Hines";
contacts[0].Phone = "206-555-0144";

contacts.Add(new ExpandoObject());
contacts[1].Name = "Ellen Adams";
contacts[1].Phone = "206-555-0155";

Technically speaking, I could write dynamic contacts = new List<ExpandoObject>() and the example would work. However, there are some situations where this could cause problems, because the actual type of the list elements should be dynamic and not ExpandoObject, and these are two different types. (Once again, references to the ExpandoObject objects are statically-typed and do not support dynamic operations.)

Now, if you want to find all the names in your contact list, just iterate over the collection.

foreach (var c in contacts)
    Console.WriteLine(c.Name);

Again, this syntax is better than LINQ to XML version.

foreach (var c in contactsXML.Descendants("Name"))
    Console.WriteLine((string)c);

So far, so good. But one of the main advantages of LINQ to XML is, well, LINQ. How would you query dynamic objects? Although there is still a lot to be done in this particular area, you can query dynamic objects. For example, let’s find all the phone numbers for the specified name.

var phones = from c in (contacts as List<dynamic>)
             where c.Name == "Patrick Hines"
             select c.Phone;

True, the cast here doesn’t look like something strictly necessary. Certainly the compiler could have determined at run-time that contacts is List<dynamic>. But as I said, there is still some work to be done in this area.

Another thing to note is that this trick works only for the LINQ to Objects provider. To use dynamic objects in LINQ to SQL or other LINQ providers, you need to modify the providers themselves, and that’s a completely different story.

However, even with the cast, syntax is still better than in a LINQ to XML query.

var phonesXML = from c in contactsXML.Elements("Contact")
                where c.Element("Name").Value == "Patrick Hines"
                select c.Element("Phone").Value;

Sure, there are some things that look better in LINQ to XML. For example, if you want to delete a phone number for all the contacts, you can write just one line of code in LINQ to XML.

contactsXML.Elements("Contact").Elements("Phone").Remove();

Since C# doesn’t have syntax for removing object members, you don’t have an elegant solution here. But ExpandoObject implements IDictionary<String, Object> to maintain its list of members, and you can delete a member by deleting a key-value pair.

foreach (var person in contacts)
    ((IDictionary<String, Object>)person).Remove("Phone");

There are other useful methods in LINQ to XML like Save() and Load(). For ExpandoObject you need to write such methods yourself, but probably only once. Here, casting to the IDictionary interface can help as well.

And although I’ve been comparing LINQ to XML and ExpandoObject in this post, these two approaches are not “rivals”. You can convert ExpandoObject to XElement and vice versa. For example, this is what the ExpandoObject to XElement conversion might look like.

private static XElement expandoToXML(dynamic node, String nodeName)
{
    XElement xmlNode = new XElement(nodeName);

    foreach (var property in (IDictionary<String, Object>)node)
    {

        if (property.Value.GetType() == typeof(ExpandoObject))
            xmlNode.Add(expandoToXML(property.Value, property.Key));

        else
            if (property.Value.GetType() == typeof(List<dynamic>))
                foreach (var element in (List<dynamic>)property.Value)
                    xmlNode.Add(expandoToXML(element, property.Key));
            else
                xmlNode.Add(new XElement(property.Key, property.Value));
    }
    return xmlNode;
}

This little trick might help you access all the LINQ to XML functions when you need them but at the same time use more convenient syntax when creating and modifying XML trees.

Of course, XML is not the only area where you can use ExpandoObject. If you heavily use reflection or work a lot with script objects, you can simplify your code with ExpandoObject. On the other hand, ExpandoObject is not the only useful class that the DLR provides. The DynamicObject class, for example, enables you to take more control over dynamic operations and define what actually happens when you access a member or invoke a method. But that’s a topic for another blog post.

One more thing to note is that libraries that look up members by name might someday adopt the DLR and implement the IDynamicMetaObjectProvider interface. (This interface actually provides all the “magic” – or dynamic dispatch – for ExpandoObject and the dynamic feature in general.) For example, if LINQ to XML implements this interface, you would be able to write dynamic contacts = new XmlElement() instead of dynamic contacts = new ExpandoObject() and perform the same operations that I have shown in the examples for the ExpandoObject type.

All the examples provided in this blog post work in Visual Studio 2010 Beta 1. If you have any comments or suggestions, you are welcome to post them here or contact the DLR team at http://www.codeplex.com/dlr. You can also write an e-mail to the DLR team at dlr@microsoft.com.

Update:

See how you can improve this example in my next post: Dynamic in C# 4.0: Creating Wrappers with DynamicObject.

Expression trees first appeared in Visual Studio 2008, where they were mainly used by LINQ providers. You can use expression trees to represent code in a tree-like format, where each node is an expression. You can also convert expression trees into compiled code and run it. This transformation enables dynamic modification of executable code as well as the execution of LINQ queries in various databases and the creation of dynamic queries. Expression trees in Visual Studio 2008 are explained in Charlie Calvert’s blog post Expression Tree Basics.

In this post I’m going to show how expression trees were extended in Visual Studio 2010 and how you can use them to generate dynamic methods (a problem that previously could be solved only by emitting MSIL). But although I strongly recommend reading Charlie’s blog post first, I still need to repeat some basics to spell out certain nuances.

Creating Expression Trees

The easiest way to generate an expression tree is to create an instance of the Expression<T> type, where T is a delegate type, and assign a lambda expression to this instance. Let’s take a look at the code.

LINQ provides a convenient syntax and many useful methods for operating with collections of objects. However, to be correctly processed by LINQ comparison methods such as Distinct or Intersect, a type must satisfy certain requirements.

Let’s take a look at the Distinct method, which returns all distinct objects from a collection.

List<int> numbers = new List<int> { 1, 1, 2, 3 };

var distinctNumbers = numbers.Distinct();

foreach (var number in distinctNumbers)

    Console.WriteLine(number);

The output is:

1

2

3

But what if you want to use the Distinct method for a collection of objects of your own type? For example, like this:

class Number

{

    public int Digital { get; set; }

    public String Textual { get; set; }

}

class Program

{

    static void Main(string[] args)

    {

       List<Number> numbers = new List<Number> {

           new Number { Digital = 1, Textual = "one" },

           new Number { Digital = 1, Textual = "one" } ,

           new Number { Digital = 2, Textual = "two" } ,

           new Number { Digital = 3, Textual = "three" } ,

           };

       var distinctNumbers = numbers.Distinct();

       foreach (var number in distinctNumbers)

                   Console.WriteLine(number.Digital);

    }

}

The code compiles, but the output is different:

1

1

2

3

Why did that happen? The answer is in the LINQ implementation details. To be correctly processed by the Distinct method, a type must implement the IEquatable<T> interface and provide its own Equals and GetHashCode methods.

So, the Number class from the previous example should actually look like this:

class Number: IEquatable<Number>

{

    public int Digital { get; set; }

    public String Textual { get; set; }

    public bool Equals(Number other)

    {

        // Check whether the compared object is null.

        if (Object.ReferenceEquals(other, null)) return false;

        // Check whether the compared object references the same data.

        if (Object.ReferenceEquals(this, other)) return true;

        // Check whether the objects’ properties are equal.

        return Digital.Equals(other.Digital) &&

               Textual.Equals(other.Textual);

    }

    // If Equals returns true for a pair of objects,

    // GetHashCode must return the same value for these objects.

    public override int GetHashCode()

    {

        // Get the hash code for the Textual field if it is not null.

        int hashTextual = Textual == null ? 0 : Textual.GetHashCode();

        // Get the hash code for the Digital field.

        int hashDigital = Digital.GetHashCode();

        // Calculate the hash code for the object.

        return hashDigital ^ hashTextual;

    }

}

But what if you cannot modify the type? What if it was provided by a library and you have no way of implementing the IEquatable<T> interface in this type? The answer is to create your own equality comparer and pass it as a parameter to the Distinct method.

The equality comparer must implement the IEqualityComparer<T> interface and, again, provide GetHashCode and Equals methods.

Here is how the equality comparer for the original Number class might look:

class NumberComparer : IEqualityComparer<Number>

{

    public bool Equals(Number x, Number y)

    {

        if (Object.ReferenceEquals(x, y)) return true;

        if (Object.ReferenceEquals(x, null) ||

            Object.ReferenceEquals(y, null))

                return false;

            return x.Digital == y.Digital && x.Textual == y.Textual;

    }

    public int GetHashCode(Number number)

    {

        if (Object.ReferenceEquals(number, null)) return 0;

        int hashTextual = number.Textual == null

            ? 0 : number.Textual.GetHashCode();

        int hashDigital = number.Digital.GetHashCode();

        return hashTextual ^ hashDigital;

    }

}

And don’t forget to pass the comparer to the Distinct method:

var distinctNumbers = numbers.Distinct(new NumberComparer());

Of course, these rules don't just apply to the Distinct method. For example, the same is true for the Contains, Except, Intersect, and Union methods. In general, if you see that a LINQ method has an overload that accepts the IEqualityComparer<T> parameter, it probably means that to use it for your own data types you need to either implement IEquatable<T> in your class or create your own equality comparer.

Let’s start with the basics and maybe repeat some information that many of you already know. One of the most important concepts in LINQ performance and optimization is, of course, deferred execution. It simply means that when you declare a variable and assign it a query expression, that expression is not executed immediately.

// Query is not executed.

var query = from item in storage select item;

The variable query now stores the command, and the query execution is deferred until you request the actual data from the query. This usually happens either within a foreach loop or when you call an aggregate method such as Min, Max, and Average, or when you cache the query results using the ToList or ToArray methods.

// foreach loop.

foreach (var item in query)

    Console.WriteLine(item);

// Count method.

int total = query.Count();

// ToArray method.

var cachedQuery = query.ToArray();

Now let’s look at what else is happening behind the scenes. Does any compiler-level optimization happen during the query execution? The answer is yes. However, there is a catch. From now on we will talk only about queries for IEnumerable and IEnumerable<T> collections that use the “LINQ to Objects” LINQ provider. For other LINQ providers, including LINQ to SQL and LINQ to XML, different optimization rules might apply.

Note: It is often believed that because of deferred execution it takes longer to execute a query for the first time. However, in the case of LINQ to Objects queries, there is no difference between the first execution and subsequent ones. With other LINQ providers the rules might be different (for example, there might be some caching going on), but you need to refer to the particular provider's documentation for details.

The LINQ to Objects queries are optimized in the following cases:

·        Some method calls are optimized if the data source implements a necessary interface. The following table lists these optimizations.

·        If there is a sequence of one or more Where operators immediately followed by a sequence of one or more Select operators, the query creates a single IEnumerable or IEnumerable<T> object and generates no intermediate ones.
Consider the following query:

var query = from item in storage

            where item.Category = "Food"

            where item.Price < 100

            select item;

In this case, only one IEnumerable object is be generated for the query.

·        If you query an array or a list, the enumerator from the IEnumerable or IEnumerable<T> interface is not used in foreach loops. Instead, a simple for loop over the length of the array or list is created behind the scenes, and the elements are accessed directly.

Furthermore, the where operators are implemented as simple if statements, so no intermediate enumerators or enumerable is created.

Once again, other LINQ providers might have their own optimization rules. But the above rules should give you some idea about how LINQ to Objects works.

[author: Alexandra Rusina, Programming Writer]

Visual Studio offers tons of useful debugging features and allows you to step through your code line-by-line. However, there are times when you don’t want to step through your application, but want to make it output simple text strings with variable values, etc.

Enter the System.Diagnostics.Debug class and its Write* methods. By using the Debug class, you can output messages similarly to the way the Win32 API function OutputDebugString. However, the beauty of the Debug class is that when you build your application using the default Release configuration in Visual Studio, no code lines are generated for your Debug.Write* class. This means there’s no performance penalty for using the Debug class in release code.

To use the Debug class, simply add the “using System.Diagnostics;” statement to your C# code file, and call Debug.Write:

Debug.Write("Hello, Debugger!");

In addition to Write, you have the possibility to call WriteIf, WriteLine and WriteLineIf. For example:

bool @this = true;
bool that = false;
Debug.WriteLineIf(@this || that, "A conditional Hello!");

When you are debugging your application under the Visual Studio debugger, all the messages that are sent out by your Write method calls end up in the Output window (View / Output menu command or Ctrl+W,O on the keyboard). However, if you are running your application outside the debugger (say, by starting it from Windows Explorer), you can still view the messages using tools like DebugView from Sysinternals.

Remember, if you build your application using the default Release configuration, even DebugView won’t show your messages because the Debug.Write* calls are eliminated altogether. You can also control code generation by defining the DEBUG conditional directive.

Tip: The .NET debugging/tracing architecture also allows you to redirect debugging messages to different destinations, such as text files. See the help topic “Trace Listeners” for more information.

[author: Jani Järvinen, C# MVP]

It is a common practice to store passwords in databases using a hash. MD5 (defined in RFC 1321) is a common hash algorithm, and using it from C# is easy.

Here’s an implementation of a method that converts a string to an MD5 hash, which is a 32-character string of hexadecimal numbers.

public string CalculateMD5Hash(string input)
{
    // step 1, calculate MD5 hash from input
    MD5 md5 = System.Security.Cryptography.MD5.Create();
    byte[] inputBytes = System.Text.Encoding.ASCII.GetBytes(input);
    byte[] hash = md5.ComputeHash(inputBytes);
 
    // step 2, convert byte array to hex string
    StringBuilder sb = new StringBuilder();
    for (int i = 0; i < hash.Length; i++)
    {
        sb.Append(hash[i].ToString("X2"));
    }
    return sb.ToString();
}

An example call:

string hash = CalculateMD5Hash("abcdefghijklmnopqrstuvwxyz");

…returns a string like this:

C3FCD3D76192E4007DFB496CCA67E13B

To make the hex string use lower-case letters instead of upper-case, replace the single line inside the for loop with this line:

sb.Append(hash[i].ToString("x2"));

The difference is the ToString method parameter.

[author: Jani Järvinen, C# MVP]

Sometimes, you might want to make your application a bit more audible. If you are using .NET 2.0, you can utilize the new System.Media namespace and its SystemSound and SystemSounds classes.

The SystemSounds class contains five static properties that you can use to retrieve instances of the SystemSound class. This class in turn contains the Play() method, which you can use to play the wave file associated with the sound in Windows Control Panel. Note that the user can also disable all sounds altogether, which would mean that no sound can be heard through the computer speakers.

To play for example the classical beep sound, you could use the following code:

System.Media.SystemSounds.Beep.Play();

Similarly, you could play the “Question” sound with this code:

System.Media.SystemSounds.Question.Play();

The System.Media namespace is defined in System.dll, so there are no new DLLs you would need to add to your project’s references to use the above code.

[author: Jani Järvinen, C# MVP]

Often, you need a way to monitor your applications once they are running on the server or even at the customer site -- away from your Visual Studio debugger. In those situations, it is often helpful to have a simple routine that you can use to log messages to a text file for later analysis.

Here’s a simple routine that has helped me a lot for example when writing server applications without an user interface:

using System.IO;
        
public string GetTempPath()
{
    string path = System.Environment.GetEnvironmentVariable("TEMP");
    if (!path.EndsWith("\\")) path += "\\";
    return path;
}

public void LogMessageToFile(string msg)
{
    System.IO.StreamWriter sw = System.IO.File.AppendText(
        GetTempPath() + "My Log File.txt");
    try
    {
        string logLine = System.String.Format(
            "{0:G}: {1}.", System.DateTime.Now, msg);
        sw.WriteLine(logLine);
    }
    finally
    {
        sw.Close();
    }
}

With this simple method, all you need to do is to pass in a string like this:

LogMessageToFile("Hello, World");

The current date and time are automatically inserted to the log file along with your message.

[author: Jani Järvinen, C# MVP]

When you have struct objects as the key in a hashtable, the lookup operation of the hashtable performs miserably. This can be attributes to the GetHashCode() function which is used internally to do the lookup.

If a struct contains only simple value types (int, short, etc.), the algorithm which computes the GetHashCode creates hashes which fall into mostly the same bucket.

Example, lets say, the hashtable creates 10 buckets. Then, most probably, all the keys are being put into the same bucket. Hence when a lookup is performed, the .NET runtime has to traverse through this entire bucket to get the value.

BUCKET1 - Value1, Value2, Value3,...,valuen
BUCKET2 - (empty)
BUCKET3 - (empty)
BUCKET4 - (empty)
BUCKET5 - (empty)
BUCKET6 - (empty)
BUCKET7 - (empty)
BUCKET8 - (empty)
BUCKET9 - (empty)
BUCKET10- (empty)

Hence, instead of the lookup operation being O(1), it becomes O(n) on an average case.

To overcome this drawback, consider overriding the GetHashCode() function and making the life easier for the .NET Runtime.

An example would be to create a string by merging all your value types in the struct and joining them by using a special character as a demarcator.

Since your struct is a lookup criteria, it is sure that all the struct values will be different, and hence the string generated is guaranteed unique.

Now the string generated has a method(GetHashCode()), since it is derived from System.Object (like all other objects). Just return the output of this API. A code example will help to understand better.

struct
{
	int a;
	short b;
	public struct(int _a, short _b)
	{
		a = _a;
		b = _b;
	}
	public override int GetHashCode()
	{
		string hash = a.ToString() + ":" b.ToString();
		return hash.GetHashCode();
	}
}

Since you are generating hashcode explicitly which is guaranteed to be unique, it will boost the performance of your lookup.

Reference: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfsystemobjectclassgethashcodetopic.asp

[author: Vipul Patel, C# MVP]

tipu_77 asked "What are microsoft suggested naming conventions in C#?"

The .NET Framework Team collects their recommendations at their

GotDotNet community site.

    which points to a fairly comprehensive MSDN page

     Design Guidelines for Class Library Developers.

         which includes the section Naming Guidelines

[Author: SantoshZ]

All the /target: options except module create .NET assemblies. Depending on the option, the compiler adds metadata for the operating system to use when loading the portable executable (PE) file and for the runtime to use in executing the contained assembly or module.

module creates a module. The metadata in the PE does not include a manifest. Module/s + manifest make an assembly - the smallest unit of deployment. Without the metadata in the manifest, there is little the runtime can do with a module.

library creates an assembly without an entry point, by setting the EntryPointToken of the PE's CLR header to 0. If you look at the IL, it does not contain the .entrypoint clause. The runtime cannot start an application if the assembly does not have an entry point.

exe creates an assembly with an entry point, but sets the Subsystem field of the PE header to 3 (Image runs in the Windows character subsystem - see the _IMAGE_OPTIONAL_HEADER structure in winnt.h). If you ILDASM the PE, you will see this as .subsystem 0x0003. The OS launches this as a console app.

winexe sets the Subsystem field to 2. (Image runs in the Windows GUI subsystem). The OS launches this as a GUI app.

[Author: SantoshZ]
See also:
Chapter 3 of Inside Microsoft .NET IL assembler (Serge Lidin, Microsoft Press)
Metadata and the PE File Structure at MSDN
An In-Depth Look into the Win32 Portable Executable File Format - Part 1 and Part 2 (Matt Pietrek, MSDN Magazine)