Future Focus I: Dynamic Lookup

by Charlie Calvert and Mads Torgersen

What is Future Focus?

This is the first of a series of monthly posts designed to give insight into the C# team’s current plans for future versions of Visual Studio. Each post will highlight one or more key subjects that will impact users of the C# language.  

It is important that readers of this column have the right expectations. The information in this column is meant to be a helpful guideline for C# developers, and not a binding commitment. We are not attempting to give a complete list of features in the product, but only to share what we can in a way that will be easily accessible to all C# developers. The Visual Studio schedule, unforeseen technical problems, intellectual property rights and competitive pressures may impact our schedule or our ability to share our plans. We will, however, do our best to keep you up to date on the latest news from the team as they design and implement future versions of the C# language.

Future focus is not designed to present a detailed specification of future features. Instead, its purpose is to outline in broad strokes, and easy to understand terms, the directions that team will take in the future.

Dynamic Lookup

The next version of Visual Studio will provide a common infrastructure that will enable all .NET languages, including C#, to optionally resolve names in a program at runtime instead of compile time. We call this technology dynamic lookup.

Work on support for dynamic lookup was begun in the CLR, but soon became part of the Dynamic Language Runtime, or DLR. The DLR provides the infrastructure on which a common set of dynamic tools can be built. For instance, the DLR provides the infrastructure for both IronRuby and IronPython. It will be the infrastructure on which the C# team implements dynamic lookup .

Support for dynamic lookup is already available in Visual Basic for .NET, where it is often known as “late binding”. The new release of .NET will provide C# developers with similar functionality, while at the same time providing a shared infrastructure for runtime name resolution across all .NET languages, including VB.

Useful Scenarios

There are three primary scenarios that will be enabled by the new support for dynamic lookup:

  1. Office automation and other COM Interop scenarios
  2. Consuming types written in dynamic languages
  3. Enhanced support for reflection

Office Automation

In the next version of Visual Studio Office automation will be easier. Developers will be freed both from the need for using a bulky type library, and the need for including optional arguments in their method calls. The support for Office Automation will be part of a general effort to enhance support for COM Interop and Office PIA.

Consuming Dynamic Languages

Dynamic languages such as IronPython or IronRuby are becoming increasingly popular. At this time, those languages can call C# code, but we can’t easily call into their code. The next version of Visual Studio will simplify the steps C# developers take to call into IronPython or IronRuby classes. This will give developers access to a useful existing code base, and an alternative way to write new code.

Call Reflection

C# developers can currently use reflection to instantiate classes and call arbitrary methods that are not known at compile time. The dynamic extensions to the C# language will make it much easier to make such calls.


The syntax that will be used for dynamic lookup has not yet been finalized. The code that I show here is therefore only a tentative sketch that reflect the team’s evolving plans.

The team is currently considering adding the keyword dynamic to the language and using it to demarcate a block of code:

 static void Main(string[] args)
        object myDynamicObject = GetDynamicObject();
        myDynamicObject.SomeMethod();         // call a method   
        myDynamicObject.someString = "value"; // Set a field
        myDynamicObject[0] = 25;              // Access an indexer

All the code that occurs in a dynamic block will potentially support dynamic lookup; even if the accessed members are not known by the C# compiler to exist, it will allow the code. At runtime the DLR will look at the actual object referenced by myDynamciObject for members with those names. It will access them if they do indeed exist, otherwise an exception is thrown. Outside of a dynamic block developers can only call C# code statically, just as they do today.

The details of the compile time process have not yet been determined. For instance, the compiler might treat all methods in a dynamic block as dynamic and only attempt to resolve them at runtime. Alternatively, it might first try to resolve them statically, and if that fails it will attempt to resolve them dynamically at runtime. As we gain more clarity on our design of this technology we will publish many more details.


In this edition of Future Focus you have learned about the team’s current plans for enabling dynamic lookup in the next version of the C# language. You have seen one tentative plan for enabling this syntax. You have also seen that dynamic lookup will be enabled for three code scenarios:

  • Office Automation in particular and COM Interop in general
  • Consuming types written in Dynamic languages
  • Enhanced support for Reflection

Mads Torgersen is a Senor Program Manager on the C# team. He has been working closely with Anders Hejlsberg and other key members of the C# team as they develop the plans for the next version of the C# language. Charlie Calvert is the C# Community PM.


kick it on DotNetKicks.com