In a nutshell, dynamic is a static type that you can use where you would use any other static type. However, it is special because it allows you to tell the compiler you are not quite sure exactly what type it references and that it should defer any irresolvable type decisions to run time. You can assign any reference or value type to an instance of dynamic. Under the hood, the compiler coupled with the Dynamic Language Runtime (DLR)^[77] produces the magic to get this done by deferring the work of the compiler to run time.

When programming in C#, you are usually programming against static .NET types that might have been coded in C#, C++/CLI, and so on. But what about when you have to interoperate with types created by dynamic languages such as IronPython or IronRuby? Or what about when you have to interoperate with COM objects that implement IDispatch to support automation via late-bound interfaces?

Let's consider COM/IDispatch interoperability for a moment. Additionally, assume that I am talking about purely late-bound IDispatch implementations rather than dual interface implementations. In C# 3.0, you had to rely on gratuitous amounts of reflection to dynamically invoke the methods and properties of an instance that just feels cumbersome and unnatural. What happens behind the scenes is that the Runtime Callable Wrapper (RCW), which acts as the proxy between the .NET runtime and the COM object, translates reflection operations into IDispatch operations. This allows you to reflect over a COM object that implements the IDispatch automation interface.

If you used VB.NET rather than C# 3.0, the experience would have been much more pleasant because VB.NET shields you from all the reflection work. Now that C# 4.0 offers dynamic type support in concert with the DLR, its functionality is at par with VB.NET with respect to working with dynamically typed objects.

To better illustrate what I am talking about, let's consider a short example. Suppose that you want to create a new Excel document with some text in the first cell. Additionally, force yourself to use only the late bound IDispatch interfaces for the sake of the example. If you are familiar with coding against Office apps such as Excel, forget for a moment the existence of Primary Interop Assemblies (PIA). The example code in C# 3.0 might look like the following:

using System;
using System.Reflection;

static class EntryPoint
{
    static void Main() {
        // Create an instance of Excel
        Type xlAppType = Type.GetTypeFromProgID( "Excel.Application" );
        object xl = Activator.CreateInstance( xlAppType );

        // Set Excel to be visible
        xl.GetType().InvokeMember( "Visible",
                                   BindingFlags.SetProperty,
                                   null,
                                   xl,
                                   new object[] { true } );

        // Create a new workbook
        object workbooks = xl.GetType().InvokeMember( "Workbooks",
                                                      BindingFlags.GetProperty,
                                                      null,
                                                      xl,
                                                      null );

        workbooks.GetType().InvokeMember( "Add",
                                          BindingFlags.InvokeMethod,
                                          null,
                                          workbooks,
                                          new object[] { −4167 } );

        // Set the value of the first cell
        object cell = xl.GetType().InvokeMember( "Cells",
                                                 BindingFlags.GetProperty,
                                                 null,

xl,
                                                 new object[] { 1, 1 } );
        cell.GetType().InvokeMember( "Value2",
                                     BindingFlags.SetProperty,
                                     null,
                                     cell,
                                     new object[] { "C# Rocks!" } );

        Console.WriteLine( "Press Enter to Continue..." );
        Console.ReadLine();
    }
}

This coding style is both ugly and cumbersome. From glancing at the code, it's difficult to tell which methods and properties of the Excel objects you are actually calling. In this code, after creating a new instance of the application, you make it visible, access the Workbooks property to create a new workbook, and then put some data in the first cell. Now, let's take a look at the new and improved way of doing this using dynamic in C# 4.0:

using System;

static class EntryPoint
{
    static void Main() {
        // Create an instance of Excel
        Type xlAppType = Type.GetTypeFromProgID( "Excel.Application" );
        dynamic xl = Activator.CreateInstance( xlAppType );

        // Set Excel to be visible
        xl.Visible = true;

        // Create a new workbook
        dynamic workbooks = xl.Workbooks;
        workbooks.Add( −4167 );

        // Set the value of the first cell
        xl.Cells[1, 1].Value2 = "C# Rocks!";

        Console.WriteLine( "Press Enter to Continue..." );
        Console.ReadLine();
    }
}

The spirit of this code is much easier to follow. You can clearly see which properties you are accessing and which methods you are calling. dynamic brings a lot to the table and facilitates more readable code in these interoperability situations.

How is this magic happening? Although dynamic is a real static type in the C# language, the compiler translates instances of dynamic into instances of object with an attribute attached to it at the CLR level. To illustrate this, consider the following code that will not compile:

class C
{
    // This will not compile!!!
    void Foo( object o ) { }
    void Foo( dynamic d ) { }
}

If you attempt to compile this code, you will get the following compiler error:

error CS0111: Type 'C' already defines a member called 'Foo' with the same parameter types

Thus, for the sake of overload resolution, dynamic and object are equal. To see the attribute in action, try compiling the following code into a library assembly:

class C
{
    void Foo( dynamic d ) { }
}

I find it easiest to just compile this on the command line using the following where <filename> is replaced with the C# code file name:

csc /target:library <filename>

Once you get this compiled, load the compiled assembly into Reflector and examine the code Reflector shows for the class. At the time of this writing, Reflector knows nothing about dynamic; the code Reflector shows can be seen here:

internal class C
{
    // Methods
    public C();
    private void Foo([Dynamic] object d);
}

You can see that the compiler attached the DynamicAttribute attribute to the parameter d to denote that it is actually dynamic.

I mentioned in a previous section that the compiler defers completion of its work until run time when it encounters dynamic types. In essence, dynamic types and dynamic expressions are opaque to the compiler; it cannot see through them. Therefore, the compiler collects all its known information and emits what's called a dynamic call site. At run time, when all type information is available, the C# runtime binder and the DLR complete the work of resolving dynamic types and performing the necessary operations.

Naturally, this means that the compiler's type system is bypassed to a certain degree at compile time. In fact, the C# runtime binder contains a subset of the compiler's functionality. When the C# runtime binder needs to throw an exception, the error message in the exception is the same one as in the compiler. This uniformity really helps when it comes to diagnosing problems at run time because you are presented with the same errors that you're familiar with. To illustrate this point, consider the following code that will not compile:

class C
{
    public void Foo() {}
}

static class EntryPoint
{
    static void Main() {
        C obj = new C();
        obj.Bar();
    }
}

As you would expect, you end up with a compiler error. The output looks like the following:

error CS1061: 'C' does not contain a definition for 'Bar' and no extension method 'Bar'
accepting a first argument of type 'C' could be found (are you missing a using directive or
an assembly reference?)

Now consider the following example, in which it actually does compile because you are using dynamic to hold the instance of C:

class C
{
    public void Foo() {}
}

static class EntryPoint
{
    static void Main() {
        dynamic dynobj = new C();
        dynobj.Bar();
    }
}

In this case, the error that you expect to see is deferred until run time, and if you execute this example, you will see the following results on the console:

Unhandled Exception: Microsoft.CSharp.RuntimeBinder.RuntimeBinderException: 'C' does not
contain a definition for 'Bar'

at CallSite.Target(Closure , CallSite , Object )

at System.Dynamic.UpdateDelegates.UpdateAndExecuteVoid1[T0](CallSite site, T0 arg0)

at EntryPoint.Main()

using System;

class C
{
    void ProcessInput( int x ) {
        Console.WriteLine( "int: " + x.ToString() );
    }

    public void ProcessInput( string msg ) {
        Console.WriteLine( "string: " + msg );
    }

    public void ProcessInput( double d ) {
        Console.WriteLine( "double: " + d.ToString() );
    }
}

static class EntryPoint
{
    static void Main() {
        dynamic obj1 = 123;
        dynamic obj2 = "C# Rocks!";
        dynamic obj3 = 3.1415;

        C c = new C();
        c.ProcessInput( obj1 );         // #1
        c.ProcessInput( obj2 );         // #2

        dynamic cObj = c;
        cObj.ProcessInput( obj3 );      // #3
    }
}

double: 123

string: C# Rocks!

double: 3.1415

class C
{
    public void ProcessInput( int x ) {
        Console.WriteLine( "int: " + x.ToString() );
    }

    public void ProcessInput( string msg ) {
        Console.WriteLine( "string: " + msg );
    }

    void ProcessInput( double d ) {
        Console.WriteLine( "double: " + d.ToString() );
    }
}

int: 123

string: C# Rocks!

Unhandled Exception: Microsoft.CSharp.RuntimeBinder.RuntimeBinderException:
 'C.ProcessInput(double)' is inaccessible due to its pr

otection level

   at CallSite.Target(Closure , CallSite , Object , Object )

at System.Dynamic.UpdateDelegates.UpdateAndExecuteVoid2[T0,T1](CallSite site, T0 arg0, T1
arg1)

at EntryPoint.Main() in dynamic_parms_2.cs:line 30

public class DynamicObject : IDynamicMetaObjectProvider
{
    ...

    public virtual IEnumerable<string> GetDynamicMemberNames();
    public virtual DynamicMetaObject GetMetaObject(Expression parameter);
    public virtual bool TryBinaryOperation(BinaryOperationBinder binder, object arg, out
object result);
    public virtual bool TryConvert(ConvertBinder binder, out object result);
    public virtual bool TryCreateInstance(CreateInstanceBinder binder, object[] args,
outobject result);
    public virtual bool TryDeleteIndex(DeleteIndexBinder binder, object[] indexes);
    public virtual bool TryDeleteMember(DeleteMemberBinder binder);
    public virtual bool TryGetIndex(GetIndexBinder binder, object[] indexes, out object
result);
    public virtual bool TryGetMember(GetMemberBinder binder, out object result);
    public virtual bool TryInvoke(InvokeBinder binder, object[] args, out object result);

public virtual bool TryInvokeMember(InvokeMemberBinder binder, object[] args, out object);
result);
    public virtual bool TrySetIndex(SetIndexBinder binder, object[] indexes, object value);
    public virtual bool TrySetMember(SetMemberBinder binder, object value);
    public virtual bool TryUnaryOperation(UnaryOperationBinder binder, out object result);

    ...
}

using System;
using System.Dynamic;
using System.Collections.Generic;

class MyDynamicType : DynamicObject
{
    public override bool TryInvokeMember( InvokeMemberBinder binder,
                                          object[] args,
                                          out object result ) {
        result = null;
        Console.WriteLine( "Dynamic invoke of " + GetType() +
                           "." + binder.Name + "()" );
        return true;
    }

    public override bool TrySetMember( SetMemberBinder binder,
                                       object Value ) {
        Console.WriteLine( "Dynamic set of property " + GetType() +
                           "." + binder.Name + " to " +
                           Value );

        return true;
    }

    public void DoDefaultWork() {
        Console.WriteLine( "Performing default work" );
    }
}

static class EntryPoint
{
    static void Main() {
        dynamic d = new MyDynamicType();

        d.DoDefaultWork();
        d.DoWork();
        d.Value = 42;

d.Count = 123;
    }
}

Performing default work

Dynamic invoke of MyDynamicType.DoWork()

Dynamic set of property MyDynamicType.Value to 42

Dynamic set of property MyDynamicType.Count to 123

using System;
using System.Runtime.InteropServices;

class C
{
    public void DoWork() {
        Console.Write( "Doing work...  " );
    }
}

static class EntryPoint
{
    [DllImport("kernel32.dll")]
    private static extern int QueryPerformanceCounter( out Int64 count );

    static void Main() {
        // Let's call DoWork once statically to get it jitted.
        C c = new C();
        c.DoWork();
        Console.WriteLine();

        dynamic d = c;

        for( int i = 0; i < 10; ++i ) {
            Int64 start, end;

            QueryPerformanceCounter( out start );
            d.DoWork();
            QueryPerformanceCounter( out end );
            Console.WriteLine( "Ticks: {0}",
                               end - start );
        }
    }
}

Doing work...

Doing work... Ticks: 83760

Doing work... Ticks: 2161

Doing work... Ticks: 1937

Doing work... Ticks: 1858

Doing work... Ticks: 1845

Doing work... Ticks: 1981

Doing work... Ticks: 1853

Doing work... Ticks: 1834

Doing work... Ticks: 1995

Doing work... Ticks: 1887

using System;

static class EntryPoint
{
    static void Main() {
        dynamic d = 42;
        ++d;

        object o = 42;
        o = (int)o + 1;

        Console.WriteLine( "d = " + d + "
o = " + o );
    }
}

Throughout the design and implementation of dynamic types in C# 4.0, the C# team had to find solutions for some seriously tricky problems. Conversions to and from dynamic types is certainly one of those problems. Recall that in C#, there are two types of conversions. They are implicit conversions and explicit conversions. Implicit conversions do not require the casting syntax, although explicit conversions do. Also, recall that for any type, you can define custom implicit and explicit conversion operators. Dynamic expressions add a whole new dimension to conversions, indeed!

Let's consider implicit conversions for a moment. What types should be implicitly convertible to dynamic? It turns out that all types are implicitly convertible to dynamic. The rules are as follows:

This is as expected because it then allows you to do the things you would expect, such as what is illustrated in the following code:

class C
{
}

static class EntryPoint
{
    static void Main() {
        dynamic d1 = 42;            // Impl. boxing conversion
        dynamic d2 = new C();       // Impl. ref. conversion
        dynamic d3 = d2;            // Impl. ident. conversion
        dynamic d4 = new object();  // Impl. ref. conversion
    }
}

What about when you need to go the other direction? Should instances of dynamic be convertible to any type? Certainly it makes sense for dynamic expressions to be explicitly convertible to static types. For the sake of discussion, think of a dynamic expression as an expression in which a component of the expression forces the entire thing to be handled dynamically. For example, the right side of the equals sign in the following statement is a dynamic expression if the variable d is a dynamic instance:

Double dbl = 3.14 + d;

Now that I have specified what I mean by a dynamic expression, consider this example:

class C
{
}

static class EntryPoint
{
    static void Main() {
        dynamic d = new C();

        // explicit cast back to C reference
        C cObj = (C) d;

        // What happens here???
        string str = d;
    }
}

I create a new instance of C and implicitly cast it to a dynamic reference. Then I explicitly cast the dynamic reference, which is a short dynamic expression, back into a reference to C, which makes sense. But isn't it cumbersome to have to explicitly cast from a dynamic expression back into reference and value types? All that casting can become laborious, especially if the type you're casting to has a long name (which is common for generic types or LINQ-generated types). Besides, all that casting goes against the spirit of dynamic expressions because they are supposed to streamline your code, making it easier to read and understand. And what about the last statement in the preceding code and what does it mean?

As it turns out, the code does compile correctly. In the last statement, the dynamic expression d is explicitly cast into a string reference, which will generate the following exception at run time:

Unhandled Exception: Microsoft.CSharp.RuntimeBinder.RuntimeBinderException: Cannot
implicitly convert type 'C' to 'string'

That's very cool, indeed. The compiler has performed the explicit cast from dynamic to string without me having to type the casting notation. In reality, I didn't have to use the cast notation when I converted the dynamic expression back into a C reference. If you load the compiled code into Reflector, you will see that it uses a call site to perform an explicit conversion. Is this more than just a convenience?

class C
{
    static public void Foo( int i ) {}
    static public void Foo( string str ) {}
}

class D { }

static class EntryPoint
{
    static void Main() {
        dynamic d = new D();

        C.Foo( d );
    }
}

Overload resolution was reasonably complicated before the introduction of dynamic. In various other parts of this book, I talked about overload resolution and how it works in the context of class methods, interface definitions, and extension methods. Dynamic types add a new dimension to overload resolution. Recall from the previous section that dynamic instance variables are implicitly convertible only to type dynamic and nothing else. So what should the compiler do when you invoke a method on a static type passing a dynamic argument?

The solution is that any time dynamic is involved in a method invocation, whether the receiver of the call is dynamic or a parameter is dynamic, overload resolution is performed at run time. That's easy! Consider the following code:

using System;

class C
{
    static public void Foo( double dbl, dynamic dyn ) {
        Console.WriteLine( "void Foo( double dbl, dynamic dyn )" );
    }
    static public void Foo( int i, string str ) {
        Console.WriteLine( "void Foo( int i, string str )" );
    }
}

static class EntryPoint
{
    static void Main() {
        dynamic d = "I'm dynamic";
        dynamic d1 = new object();

        C.Foo( 3.1415, d );            // is it a compile-time overload?
        C.Foo( 42, d );                // run-time overload
        C.Foo( 42, d1 );               // run-time overload

        // The following will not compile!
        // C.Foo( "Hello!", d );
    }
}

The first call to C.Foo matches the signature of the first overload perfectly, even though it has dynamic in its call. You might think the compiler would automatically choose the first overload at compile time, but it does not (otherwise, it would be breaking the dynamic overload resolution rule just stated). The second call defers overload selection until run time, even though both parameters are implicitly convertible to the first overload. That is, int is implicitly convertible to double, and dynamic is implicitly convertible to dynamic. Although the behavior of the second call to C.Foo might seem counterintuitive at first because int is implicitly convertible to double and dynamic is implicitly convertible to dynamic, consider the third call to C.Foo (maybe it will make more sense after you see the following results). The output from the code is shown here:

void Foo( double dbl, dynamic dyn )

void Foo( int i, string str )

void Foo( double dbl, dynamic dyn )

You see, even though in the final two calls to C.Foo, the parameters are both implicitly convertible to the first overload of C.Foo, you don't want the compiler to make the choice at compile time. That's because the dynamic instance's type can be inspected at run time and a more precise choice can be made based on that information.

Finally, notice the last call to C.Foo that I have commented out in the code. It will not compile as written. If every call that involves dynamic is resolved at run time, how is this so? The compiler actually has examined the candidate set of methods and is telling you that there is no chance that an overload will be found at run time. So even though the actual choice of overload is determined at run time, the compiler still applies as much logic as possible at compile time to avoid a situation in which a run-time exception is guaranteed.

Remember, dynamic is implemented internally as a reference to object with an attribute attached. Therefore, you cannot have overloads within a type in which a single parameter position differs only between dynamic and object. For example, the following will not compile:

class C
{
    // Can't do this!!!
    public void DoWork( object o ) { }
    public void DoWork( dynamic d ) { }
}

If you attempt to compile something like this, you will get a compiler error like the following:

Type 'C' already defines a member called 'DoWork' with the same parameter types

dynamic brings with it some complexities when it comes to inheritance. Does it make sense to be able to derive from dynamic? Is it possible to derive from a generic base type in which one of the generic arguments is dynamic? And is it possible to implement a generic interface in which one of the generic arguments is dynamic? I will be digging into them in this section, but first let's talk about the things you cannot do with inheritance and dynamic.

// This will not compile!!!
class C : dynamic
{
}

error CS1965: 'C': cannot derive from the dynamic type

// This will not compile!!!
interface IWork<T>
{
    void DoWork( T item );
}

class C : IWork<dynamic>
{
    public void DoWork( dynamic item ) {
    }
}

error CS1966: 'C': cannot implement a dynamic interface 'IWork<dynamic>'

//This will not compile!!!
using System;

class SpecialAttribute : Attribute
{
}

interface IWork<T>
{
    void DoWork( T item );
}

class C : IWork< [Special] object >
{
    public void DoWork( [Special] object item ) {
    }
}

generic_attribute.cs(13,18): error CS1031: Type expected
generic_attribute.cs(13,35): error CS1519: Invalid token '>' in class, struct, or
interface member declaration

interface IWork<T>
{
    void DoWork( T item );
}

class C : IWork<object>
{
    public void DoWork( object item ) {
        dynamic d = item;

        // Now complete the work with the
        // dynamic thing.
    }
}

static class EntryPoint
{
    static void Main() {

C c = new C();
        dynamic d = new object();

        c.DoWork( d );
    }
}

using System;
using System.Collections.Generic;

class C
{
}

static class EntryPoint
{
    static void Main() {
        IList<dynamic> myList = new List<dynamic>();

        myList.Add( new C() );
        myList.Add( new object() );

        foreach( dynamic item in myList ) {
            Console.WriteLine( item.GetType() );
        }
    }
}

C
System.Object

using System;

class B<T>
{
    public T Value { get; set; }
}

class C : B<dynamic>
{
}

static class EntryPoint
{
    static void Main() {
        C c = new C();

        c.Value = "C# Rocks!";
        Console.WriteLine( c.Value.GetType() );
    }
}

[Dynamic(new bool[] { false, true })]
internal class C : B<object>
{
    // Methods
    public C();
}

static class EntryPoint
{
    static void Main() {
        C c = new C();

        c.Value = "C# Rocks!";
        Console.WriteLine( 42 + c.Value );
    }
}

42C# Rocks!

error CS0019: Operator '+' cannot be applied to operands of type 'int' and 'object'

Duck typing is where the type of an object is determined by the contract it supports rather than actual interfaces or base types that it derives from. Duck typing is common in some C++ template libraries, in which where you can do something similar to the following C# code that will not compile:

// This will not compile!!!
class C<T>
{
    static public void DoWork( T item ) {
        item.DoWork();
    }
}

If you attempt this code, you are greeted with the following compiler error:

error CS1061: 'T' does not contain a definition for 'DoWork' and no extension method
'DoWork' accepting a first argument of type 'T' could be found (are you missing a using
directive or an assembly reference?)

Instead, you must use generic constraints to do anything close to the intended effect of the previous code. However, constraints still don't get you duck typing because you are relying upon type definitions. Wouldn't it be nice to be able to say, "whatever type T is, I want to invoke the DoWork method" without having to have T implement an interface that includes a definition for DoWork?

The irony is that the C# compiler does exactly this. Consider the following code:

using System;
using System.Collections;

class C
{
    public IEnumerator GetEnumerator() {
        long l = 0;
        while( l < 10 ) {
            yield return ++l;
        }
    }
}

static class EntryPoint
{
    static void Main() {
        C c = new C();

        foreach( var item in c ) {
            Console.Write( item + ", " );
        }
    }
}

When you execute code, it simply prints out these integers:

1, 2, 3, 4, 5, 6, 7, 8, 9, 10,

The functionality of the program is not exciting, but what is interesting is the foreach statement in bold. Recall that behind the scenes, the compiler calls GetEnumerator on the collection object on which you want to iterate. And as you probably know, GetEnumerator is part of the IEnumerable and IEnumerable<T> interfaces. However, notice that class C implements neither of these interfaces! It is a common misconception that the type foreach iterates over needs to implement one of the IEnumerable interfaces. Instead, the compiler just compiles in a call to GetEnumerator on whatever instance foreach is iterating over. In fact, if you were to comment out the GetEnumerator method and attempt to recompile, the compiler would tell you the following:

error CS1579: foreach statement cannot operate on variables of type 'C' because 'C' does not
contain a public definition for 'GetEnumerator'

This behavior of the compiler is a perfect example of duck typing at work. After all, the compiler does not care what type is given to foreach or whether it implements some particular interface; instead it just wants that type to implement a specific method with a specific signature. However, prior to C# 4.0, this capability was virtually impossible in code.

Now, let's look at how you can achieve this same result using type dynamic. Imagine that you are adding new features to a very large and mature application. Furthermore, you have identified that during testing it would be extremely handy to be able to dump detailed state information about objects to a debug log by calling a method named DumpStateTo. Because this is a large mature application, there are literally thousands of types defined. Therefore, it is unfeasible due to time constraints to define a new interface and expect all the types to implement it. So let's look at how this could be implemented in C# using dynamic:

using System;
using System.IO;
using Microsoft.CSharp.RuntimeBinder;

class C
{
    public void DumpStateTo( TextWriter tw ) {
        tw.WriteLine( "This is the state for a " +
                      GetType() + " instance" );
        tw.WriteLine( "	Value == " + Value );
    }

    public long Value { get; set; }
}

class D
{
}

static class EntryPoint
{
    static void Main() {
        C c = new C();
        c.Value = 42;

        D d = new D();

        // Now let's dump some debug info
        DumpDebugInfo( c );
        DumpDebugInfo( d );
    }

    static void DumpDebugInfo( dynamic d ) {
        // We don't want a lack of the DumpStateTo() method to
        // crash the application.
        try {
            Console.WriteLine( "--------------------------------" );
            d.DumpStateTo( Console.Out );
        }
        catch( RuntimeBinderException rbe ) {
            Console.WriteLine( "Failed to dump state for: " +
                               d.GetType() );
            Console.WriteLine( "	" + rbe.Message );
        }
    }
}

This example created an instance of both C and D, and you then pass them to DumpDebugInfo, which is a wrapper around calls to DumpStateTo. Notice that DumpDebugInfo achieves duck typing by accepting a parameter of type dynamic. Also, it is very important to catch any runtime binder exceptions because, as stated, this fictional large application has thousands of types that might or might not implement DumpStateTo. The results of the preceding code are shown here:

--------------------------------

This is the state for a C instance

        Value == 42

--------------------------------

Failed to dump state for: D

'D' does not contain a definition for 'DumpStateTo'

In a real-world implementation, you might also want to include other information that would help you identify exactly which instance is dumped so you can find it easily in a debugger.

One of the biggest differences between duck typing in C# using dynamic as opposed to duck typing in some static languages, such as C++ using templates, is that type errors are deferred until run time, whereas in C++ they are discovered at compile time. This is actually a big deal, indeed. You should use duck typing with dynamic sparingly and carefully for the sake of robustness. If you must heavily rely on dynamic duck typing, be sure to implement good error-handling mechanisms. Throughout this book, I have stressed the importance of using the compiler as your friend to catch as many programming errors as possible at compile time rather than run time. That was one of the motivating factors behind implementing generics in C# 2.0. But with dynamic duck typing, you are throwing all that out of the window so you must be prepared to handle the unintended consequences.

The new dynamic type was no easy feat to implement. There are some things you simply cannot do with dynamic. Some of those things just don't make sense, and others do, but the C# team might have not had enough time to implement them properly. Furthermore, just as with any other new feature in a programming language, you will learn more about it and its uses over time while using it. In other words, don't be surprised if the use of dynamic evolves over the coming years as the language matures.

As it stands, you cannot use the extension method syntax with type dynamic in C# 4.0. This might change in future versions, though. As I mentioned before, you also cannot implement dynamic interfaces; that is, interfaces where you specify dynamic as one of the type parameters. Also, you cannot use dynamic in constraint clauses.

Up to this point in this chapter, you have seen how the dynamic type facilitates interoperability and how to treat any type instance as a dynamic instance. But what about creating types dynamically at run time?

Since the initial release of the .NET Framework, you have always been able to create code dynamically using the facilities within the System.Reflection.Emit namespace. But doing so is no trivial task. Starting with .NET 4.0, the DLR team provides the System.Dynamic.ExpandoObject, which makes it incredibly easy to create dynamic instances of objects. Let's go ahead and look at an example:

using System;
using System.Dynamic;
using System.Collections.Generic;

static class EntryPoint
{
    static void Main() {
        // Create the kennel
        dynamic dogKennel = new ExpandoObject();

        // Set some useful properties
        dogKennel.Address = "1234 DogBone Way";
        dogKennel.City = "Fairbanks";
        dogKennel.State = "Alaska";

        dogKennel.Owner = new ExpandoObject();
        dogKennel.Owner.Name = "Ginger";

        // Setup a collection of dynamic dogs
        dogKennel.Dogs = new List<dynamic>();

        // Create some dogs
        dynamic thor = new ExpandoObject();
        thor.Name = "Thor";
        thor.Breed = "Siberian Husky";

        dynamic apollo = new ExpandoObject();
        apollo.Name = "Apollo";
        apollo.Breed = "Siberian Husky";

        // Put the dogs in the kennel
        dogKennel.Dogs.Add( thor );
        dogKennel.Dogs.Add( apollo );
    }
}

The first thing to notice is that when I created the new instance of ExpandoObject, I assigned it to a variable of type dynamic that is essential because ExpandoObject implements IDynamicMetaObjectProvider, through which it gets its special powers. Notice that I populated the properties on the object by simply assigning to them as if they already existed. In reality, this operation creates the property and assigns it at the same time. This magic is performed by ExpandoObject's implementation of IDynamicMetaObjectProvider, which adds an entry to an internal dictionary. To create contained objects in the dogKennel object, simply assign a new instance of ExpandoObject to a property name as I did with dogKennel.Owner. If you need your dynamic object to contain a collection of objects, simply assign a new instance of a container object to a new property, as I did when I assigned an instance of List<dynamic> to dogKennel.Dogs. I set the generic argument to dynamic in the collection type because I want the contained objects to also be dynamic objects that I can create with ExpandoObject. I'm sure you will agree that using ExpandoObject to create dynamic object instances is much easier than using System.Reflection.Emit.

What if you want to enumerate the properties of the dynamic instance without having to know what they are ahead of time? For example, what if you need a method named PrintExpandoObject to print the contents of any dynamic ExpandoObject instance to the console? This is easy to do because ExpandoObject implements IDictionary<string, object>, through which you can enumerate the properties contained within the ExpandoObject instance. For example, one implementation for PrintExpandoObject could look like the following:

static void PrintExpandoObject( dynamic obj,
                                string name,
                                int indent = 0 ) {
    Func<int, string> createPad = (n) => {
           return string.Join("", Enumerable.Repeat("   ", n) );
    };

    Console.WriteLine( createPad(indent) + name + ":" );
    ++indent;

    var dict = (IDictionary<string, object>) obj;
    foreach( var property in dict ) {
        if( property.Value is ExpandoObject ) {
            // Recurse to print the contained ExpandoObject
            PrintExpandoObject( property.Value,
                                property.Key,
                                indent );
        } else {
            if( property.Value is IEnumerable<dynamic> ) {
                string collName = property.Key;
                Console.WriteLine( "{0}{1} collection:",
                                   createPad(indent),
                                   collName );
                int index = 0;
                foreach( var item in
                         (IEnumerable<dynamic>)property.Value ) {
                    string itemName =
                        string.Format( "{0}[{1}]",
                                       collName,
                                       index++ );

                    // Recurse for this instance
                    PrintExpandoObject( item,
                                        itemName,
                                        indent+1 );
               }
           } else {
               Console.WriteLine( "{0}{1} = {2}",
                                  createPad(indent),
                                  property.Key,
                                  property.Value );
           }
        }
    }
}

In the example in which I created the dogKennel instance, I could have added the following code afterward:

PrintExpandoObject( dogKennel, "Ginger's Kennel" );

Notice that for each key/value pair within the dictionary I test whether the value is also another instance of ExpandoObject. If so, I make a recursive call into PrintExpandoObject to print it. Likewise, if the value is an enumerable type, I iterate through the enumerable items, assuming that they are instances of ExpandoObject and recurse for them as well. In an attempt to make the output a little bit prettier, I have passed an indention value down through the stack, thus producing output that looks similar to the following:

Ginger's Kennel:

Address = 1234 DogBone Way

   City = Fairbanks

   State = Alaska

   Owner:

      Name = Ginger

   Dogs collection:

      Dogs[0]:

         Name = Thor

         Breed = Siberian Husky

      Dogs[1]:

         Name = Apollo

Breed = Siberian Husky

I have assigned the ExpandoObject to a variable of type dynamic rather than a variable of type ExpandoObject. Although I could have assigned it to variable of type ExpandoObject, it would have meant that the only way to add properties would have been through the methods associated with the IDictionary<string, object> interface. Obviously, that's not as slick as creating the properties on the fly, as already shown. Incidentally, the only way to remove properties from ExpandoObject instances is via the methods associated with the IDictionary<string, object> interface.

But what about dynamic methods? So far, I have only shown you how to create properties on ExpandoObject instances via a variable of type dynamic. Actually, it's just as easy to create dynamic methods, too. Here is an instance called dynamicExpression that contains a collection of coefficients for computing a univariate polynomial:

using System;
using System.Dynamic;
using System.Linq.Expressions;
using System.Collections.Generic;

static class EntryPoint
{
    static void Main() {
        dynamic dynamicExpression = new ExpandoObject();

        // Add the coefficients
        dynamicExpression.Coefficients = new List<dynamic>();
        dynamicExpression.Coefficients.Add( 2 );
        dynamicExpression.Coefficients.Add( 5 );
        dynamicExpression.Coefficients.Add( 3 );

        // Create dynamic method
        dynamicExpression.Compute =
            new Func<double, double>( (x) => {
                double result = 0;

                for( int i = 0;
                     i < dynamicExpression.Coefficients.Count;
                     ++i ) {
                    result +=
                        (double)dynamicExpression.Coefficients[i] *
                        Math.Pow( x, (double) i );
                }

                return result;
            } );

        // Let's compute a value now
        Console.WriteLine( dynamicExpression.Compute(2) );
    }
}

I have bolded the area in the code where I create and then call the dynamically created method named Compute. All you have to do is create a delegate instance and assign it to a property on the ExpandoObject instance where the name of the property is the same name you want associated with the method. Then ExpandoObject's implementation of IDynamicMetaObjectProvider allows you to simply call through to that delegate using the familiar method invocation syntax as long as you invoke the method through a variable of type dynamic. In the previous code, I used the Func<> delegate type, along with a lambda expression, to provide the delegate.

This chapter covered the dynamic type added to the language in C# 4.0. Interoperability is the major theme regarding dynamic types. Now it becomes much easier to interface with dynamic languages such as IronPython and IronRuby, as well as legacy COM automation objects. Code that interacts with those technologies becomes cleaner and clearer. I also showed how you use the ExpandoObject type to create dynamically typed objects at run time. Additionally, C# has finally gained parity with Visual Basic in the ease of interoperability arena.

However, such power often comes with its dangers and dynamic types are no exception. When misused, you can bypass the stringent static type checking of the compiler, thus introducing unwanted bugs lurking in the shadows. Also, working with dynamic types can become slightly tricky in some situations, especially with regard to run-time type conversion and overload resolution.

As with any powerful capability of the language, to use it sparingly and with caution is to use it wisely. For example, when object-oriented languages became all the rage, everyone began using inheritance as if it were the end-all solution. Experience quickly showed that instead, when misused, it creates software that is virtually impossible to maintain. In short, when being dynamic, be wise about it.