Why do COM libraries used with C # 4.0 require such heavy use of dynamic types?

Question

In demos of C # 4.0, I see a lot of code using a dynamic type. For example, the following code sets the value of an Excel cell:

excel.Cells [1, 1] .Value = ...

However, you can also access the cell in an early way with a throw:

((Range) excel.Cells [1, 1]). Value = ...;

Why doesn't Excel Excel COM library just describe cell type as range type? Similarly, all arguments to the following method are dynamic:

excel.ActiveWorkbook.Charts.Add (...)

Why were the arguments not static? Considering the Excel object model, dynamic types exist around the world. Is it because of limitations in expressiveness in COM? Is there a pattern when COM libraries use dynamic types rather than static types?

Answer 1

The COM library provides this as an option, which can mean any number of things. This is really an Office bug library for doing so many things with options.

The dynamic type is the closest .NET equivalent to the variant (it now exists), but the team did not want to modify tlbimp to generate dynamic types in the PIA for backward compatibility reasons. You will only get an “option for dynamic” conversion to C # 4 when binding PIA (creating bits that you use in your own assembly) instead of referencing it.

Answer 2

In demos of C # 4.0, I see a lot of code using a dynamic type.

Since dynamic is one of the biggest changes in C # 4.0, I would be very surprised if it weren’t. This does not mean that you should immediately start writing all your code with dynamic - just so you know when it might be useful.

Of course, variable and optional / named argument changes are evaluated, but of course they do a much shorter demonstration.

Historically, Office (in particular) has been such a pig to program against, this is a "big thing" for people who automate Office.

• people who consume COM (and Office especially)
• people who consume DLR types (IronPython, etc.)
• people who speak with dynamic systems like javascript (Silverlight etc.)

Personally, I don't expect dynamic revolutionize C # programming, but for some people it's great:

Answer 3

In fact, this is because the Office com library was created with Visual Basic in mind.

Moreover, you might think that a whole hierarchy of objects was created for VB (a simple VB without .net). And VB has historically created such a way that it simply uses the IDispatch'able COM interfaces from it (using late binding).

And now we have the burden of backward compatibility.