Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Under which application development scenarios C# dynamics and ExpandoObject can be used or when to consider using c# dynamics and ExpandoObject

share|improve this question

closed as not a real question by gnat, Kilian Foth, BЈовић, Glenn Nelson, Walter Feb 15 '13 at 12:47

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.If this question can be reworded to fit the rules in the help center, please edit the question.

One scenario where I've seen dynamic used effectively was in the implementation of feature toggles.

We had a globally accessible FeatureToggles class which was a dynamic object, therefore in our code we could make certain features of the code dependent on the toggle being enabled eg:

public void DoSomething()
    if (FeatureToggles.SomeFeatureEnabled)

The feature toggles were configured in the application configuration file, and the dynamic FeatureToggles object read the app config at startup. If a feature toggle was enabled in the config, the FeatureToggles class would return true; if a feature toggles was not enabled, or was not yet in the configuration file, the FeatureToggles class would return false. Crucially, this enabled us to start using feature toggles before they had even been configured*, in which case they defaulted to off.

* naturally there was logging output in this case.

share|improve this answer

One edge case where dynamic is not necessary, but can make your code more DRY and not actually less type-safe is when implementing the visitor pattern.

The classical way to implement this is to have an Accept(Visitor visitor) method on each derived type and you have to implement it with the same visitor.Visit(this) boilerplate.

And this assumes the types in question support the visitor. If not, you need one big if (obj is DerivedType1) … else if (obj is DerivedType2) … else if … and modify it each time new type is added (along with adding the overload of Visit() for the new type).

With dynamic, it's a matter of single line to cast your type to dynamic, which means the correct overload will be chosen:

public void Visit(BaseType obj)

protected virtual void VisitInternal(DerivedType1 obj)

protected virtual void VisitInternal(DerivedType2 obj)

// etc.
share|improve this answer

This might be my personal opinion but : Never

You are using C#. Static typed language. And probably one of the reasons why are you using it is because you like the safety of static typing for various reasons. If you wanted to sacrifice it, you would be using real dynamic language like Python or Ruby.

share|improve this answer
Why the down votes? I agree with @Euphoric: Do not use dynamics if you can avoid it. – jgauffin Feb 15 '13 at 9:44
This answer not constructive. There are cases where dynamics make sense, but using a different language is not an option. And the answer above was "never", not "if you can avoid it" – Doc Brown Feb 15 '13 at 10:01
Apparently Office interop is one area where it makes your life much easier; it'd be at least one situation where opting for dynamic is the lesser of two evils. Here's another interop example, although the use here is perhaps arguable. – Daniel B Feb 15 '13 at 11:37

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