I have been recently studying more on the dynamic types in C#. With some examples I understood once the code is compiled, it does not need to be recompiled again but can be executed directly.

I feel the flexibility provided by the keyword to actually be able to change data type at will is a great advantage.


Are there any specific shortcomings apart from wrong dynamic method calls which throw run time exceptions which developers must know before starting the implementation.

  • 3
    In C# 3, I always considered the use of object or direct type casts to be a code-smell. In almost every case it meant that I or one of my team hadn't designed an appropriate interface for that functionality. I'm guessing that if I were using C# 4 now, I would feel pretty much the same way about use of dynamic too. I could see the case for it if you make everything dynamic, but in that case you might as well have selected a dynamic typed language in the first place. *8')
    – Mark Booth
    Feb 15, 2012 at 11:47
  • @MarkBooth +1 for the perspective. Is it then safe to say that the core implementation using C# is still going to remain strongly typed in-spite of introducing dynamic types in 4.0 Feb 15, 2012 at 11:56
  • Using dynamic in C# means you don't have to drop out to IronPython if all you need is some dynamic typing for a small part of your code. For an expression evaluator, I've had great success using dynamic to represent the operands of an expression and the results from evaluation.
    – Ed James
    Feb 15, 2012 at 15:41
  • @EdJames - That sounds like a great use of dynamic, plus I wish I'd known about IronPython when I was developing with .Net - it could have made certain things we were trying to do much easier.
    – Mark Booth
    Feb 21, 2012 at 14:40

4 Answers 4


The main shortcoming is that you throw away one of the main properties (not necessarily advantages) of C# - that it is statically typed (and for most part type safe).

The problem with dynamic typing is that it often hides bugs that would be otherwise revealed during compilation. Such bug then only manifests on run-time, which of course makes it much harder to detect.

There are IMO very few reasons to use dynamic typing in C#, the main one being collaboration with dynamically typed languages (which is AFAIK the reason dynamic was introduced in the first place).

If you want to do fully dynamically typed programming, you should look at some language which is designed to be dynamic, not hack C# to be dynamic. You can use for example IronPython if you want to use .Net libraries

  • +1 for IronPython. This means that this could lead to maintenance issues in the long run. Feb 15, 2012 at 10:53
  • 6
    The big thing that dynamic gives you is the ability to up-cast an object to its actual type without any kind of reflection hack. For example if Base foo = new Derived(); and there were two overloaded methods Moo(Base x) and Moo(Derived x), then Moo(foo) calls Moo(Base x), but Moo((dynamic)foo) calls Moo(Derived x). This leads to a very elegant implementation of the Visitor pattern for example: code.logos.com/blog/2010/03/… and is in general a very powerful technique.
    – user23157
    Feb 15, 2012 at 12:56
  • @TheMouthofaCow Nice, there surely are a few other "legitimate" uses for dynamic as well, however these are few and far in between (and you definitely have to know what you are doing before attempting something like this). Feb 15, 2012 at 13:14
  • @TheMouthofaCow A relatively new design pattern ( The Visitor Pattern ) to note. Thanks. Feb 15, 2012 at 13:34
  • 1
    Yes, it's pretty cool. I came up with it independently last week, so it was nice to see that it is an accepted idea that's been adopted into the C# arsenal.
    – user23157
    Feb 15, 2012 at 15:05

I'm not sure what kind of shortcomings are you looking for, but if you want to know about features that work with static typing, but not with dynamic, there are few:

  1. Extensions methods don't work. This is probably the biggest one. If you have dynamic collection, you can't use code like collection.Distinct(). That's because available extension methods depend on namespace usings and the DLR has no way of knowing them.

    As a workaround, you can either invoke the method as if it was normal static method: Enumerable.Distinct(collection). Or you can change the type of the collection to something like IEnumerable<dynamic>.

  2. foreach requires IEnumerable. In normal C#, foreach is pattern-based. That is, it doesn't require any specific interface, just a GetEnumerator() method that returns suitable object. If you use foreach on dynamic, the implementation of IEnumerable is required. But since the reason for this behavior is that C# 1.0 didn't have generics, this "shortcoming" is pretty much irrelevant.

  • 1
    +1 for extensions method. Does this also apply to other LINQ query operators like GroupBy() ? Feb 15, 2012 at 12:34
  • 2
    @Karthik: Yes it does. I think extension methods are compile time syntactic sugar, hence the fact that they don't get resolved.
    – user23157
    Feb 15, 2012 at 12:46
  • @TheMouthofaCow +1 - Thanks for the clarification. Feb 15, 2012 at 12:48
  • 1
    I agree with the extension methods, i.e how the dynamic cannot figure out extension methods at run time but I could not follow the dynamic collection you have explained. Feb 24, 2012 at 7:13

The problem with dynamic types (not variables declared as dynamic) in .net is that they don't have a lot of the functionality available to static types.

  • there's no reflection (you can iterate over members but not much else)
  • no metadata (there goes your validation in dynamic data sites/mvc)
  • absolutely no checking at compile time (any misspellings will not be caught)
  • since this is a powerful feature noobs may tend to abuse/misuse/misunderstand it
  • code written with dynamic types tends to be hard to maintain and damn hard to refactor
  • because of duck typing and other features gurus may write code that is unreadable to anyone else

So don't write code with dynamic types unless you know what you are doing.


Since dynamic is just a marked object it boxes value types.

This can have performance implications, but since I'd use static typing in performance critical code anyways, that's probably not a problem in practice.

This boxing also interferes with mutable value types. If you modify them with dynamic, you only modify the boxed copy. But since you should not use mutable value types in the first place, this isn't a big problem either.

  • +1 I definitely agree. Static typing would be the best approach for performance critical code. Feb 16, 2012 at 2:47

Not the answer you're looking for? Browse other questions tagged or ask your own question.