Differences between ExpandoObject, DynamicObject and dynamic

The dynamic keyword is used to declare variables that should be late-bound.
If you want to use late binding, for any real or imagined type, you use the dynamic keyword and the compiler does the rest.

When you use the dynamic keyword to interact with a normal instance, the DLR performs late-bound calls to the instance's normal methods.

The IDynamicMetaObjectProvider interface allows a class to take control of its late-bound behavior.
When you use the dynamic keyword to interact with an IDynamicMetaObjectProvider implementation, the DLR calls the IDynamicMetaObjectProvider methods and the object itself decides what to do.

The ExpandoObject and DynamicObject classes are implementations of IDynamicMetaObjectProvider.

ExpandoObject is a simple class which allows you to add members to an instance and use them dynamically.
DynamicObject is a more advanced implementation which can be inherited to easily provide customized behavior.

I will try to provide a clearer answer to this question, to explain clearly what the differences are between dynamic, ExpandoObject and DynamicObject.

Very quickly, dynamic is a keyword. It is not a type per-se. It is a keyword that tells the compiler to ignore static type checking at design-time and instead to use late-binding at run-time. So we're not going to spend much time on dynamic in the rest of this answer.

ExpandoObject and DynamicObject are indeed types. On the SURFACE, they look very similar to each other. Both classes implement IDynamicMetaObjectProvider. However, dig deeper and you'll find they're NOT similar at all.

DynamicObject is a partial implementation of IDynamicMetaObjectProvider purely meant to be a starting point for developers to implement their own custom types supporting dynamic dispatch with custom underlying storage and retrieval behavior to make dynamic dispatch work.

1. DynamicObject can't be constructed directly.
2. You MUST extend DynamicObject for it to have any use to you as the developer.
3. When you extend DynamicObject you are now able to provide CUSTOM behavior regarding how you want dynamic dispatch to resolve to data stored internally in your underlying data representation at run-time.
4. ExpandoObject stores underlying data in a Dictionary, etc. If you implement DynamicObject, you can store data wherever and however you like. (e.g. how you get and set the data on dispatch is entirely up to you).

In short, use DynamicObject when you want to create your OWN types that can be used with the DLR and work with whatever CUSTOM behaviors you'd like.

Example: Imagine that you'd like to have a dynamic type that returns a custom default whenever a get is attempted on a member that does NOT exist (i.e. has not been added at run time). And that default will say, "I'm sorry, there are no cookies in this jar!". If you want a dynamic object that behaves like this, you'll need to control what happens when a field is not found. ExpandoObject will not let you do this. So you'll need to create your own type with unique dynamic member resolution (dispatch) behavior and use that instead of the ready-built ExpandoObject.

You can create a type as follows: (Note, the below code is just for illustration and may not run. To learn about how to properly use DynamicObject, there are many articles and tutorials elsewhere.)

public class MyNoCookiesInTheJarDynamicObject : DynamicObject
{
    Dictionary<string, object> properties = new Dictionary<string, object>();

    public override bool TryGetMember(GetMemberBinder binder, out object result)
    {
        if (properties.ContainsKey(binder.Name))
        {
            result = properties[binder.Name];
            return true;
        }
        else
        {
            result = "I'm sorry, there are no cookies in this jar!"; //<-- THIS IS OUR 
            CUSTOM "NO COOKIES IN THE JAR" RESPONSE FROM OUR DYNAMIC TYPE WHEN AN UNKNOWN FIELD IS ACCESSED
            return false;
        }
    }

    public override bool TrySetMember(SetMemberBinder binder, object value)
    {
        properties[binder.Name] = value;
        return true;
    }

    public override bool TryInvokeMember(InvokeMemberBinder binder, object[] args, out object result)
    {
        dynamic method = properties[binder.Name];
        result = method(args[0].ToString(), args[1].ToString());
        return true;
    }
}

Now, we could use this imaginary class we just created as a dynamic type that has a very custom behavior if the field doesn't exist.

dynamic d = new MyNoCookiesInTheJarDynamicObject();
var s = d.FieldThatDoesntExist;

//in our contrived example, the below should evaluate to true
Assert.IsTrue(s == "I'm sorry, there are no cookies in this jar!")

ExpandoObject is a FULL implementation of IDynamicMetaObjectProvider, where the .NET Framework team has made all of these decisions for you. This is useful if you don't need any custom behavior, and you feel that ExpandoObject works good enough for you (90% of the time, ExpandoObject is good enough). So for example, see the following, and that for ExpandoObject, the designers chose to throw an exception if the dynamic member does not exist.

dynamic d = new ExpandoObject();

/*
The ExpandoObject designers chose that this operation should result in an 
Exception. They did not have to make that choice, null could 
have been returned, for example; or the designers could've returned a "sorry no cookies in the jar" response like in our custom class. However, if you choose to use 
ExpandoObject, you have chosen to go with their particular implementation 
of DynamicObject behavior.
*/

try {
var s = d.FieldThatDoesntExist;
}
catch(RuntimeBinderException) { ... }

So to summarize, ExpandoObject is simply one pre-chosen way to extend DynamicObject with certain dynamic dispatch behaviors that will probably work for you, but may not depending on your particular needs.

Whereas, DyanmicObject is a helper BaseType that makes implementing your own types with unique dynamic behaviors simple and easy.

A useful tutorial on which much of the example source above is based.