Small place on Earth

Visual Basic hides virtual methods from C#? Not really!

Alex Ghiondea - MSFT — Wed, 27 Jan 2010 23:28:00 GMT

I was recently asked to investigate a potential issue about the C# to Visual Basic language inter-op. The punch line was that C# could not call a method defined in a library written in Visual Basic. However, if you used C# or Visual Basic for both assemblies, everything worked as expected.

The Visual Basic code used to produce the library is:

  1: Public MustInherit Class Base
  2:     Public Overridable Sub Print()
  3:     End Sub
  4: 
  5:     Public Overridable Sub Print(ByVal preview As Boolean)
  6:     End Sub
  7: End Class
  8: 
  9: 
 10: Public MustInherit Class Derived
 11:     Inherits Base
 12: 
 13:     Public Overrides Sub Print()
 14:     End Sub
 15: End Class

For those who are not proficient in Visual Basic the code means that Base is an abstract class (MustInherit) with two virtual (Overridable) methods called Print. The Derived class is also abstract and derives from Base. If defines a method that overrides the method Print (the one without any parameters).

Here is the C# code that references the library:

  1: public class MyClass : VBLibrary.Derived
  2: {
  3:     public void Foo()
  4:     {
  5:         Print(true);
  6:     }
  7: }

When you compile the C# code referencing the Visual Basic library you get this error:

CS1501: No overload for method 'Print' takes 1 arguments

Inspecting the VB library with ILDasm shows that both Print methods are emitted by the VB compiler. Since the methods are emitted in the library and when using C# to write the library the code compiles, let’s see if there is a difference between the code generated by the VB compiler and the one generated by the C# compiler.

The code generated by the Visual Basic compiler for the Derived.Print() method is this:

  1:  .method public virtual instance void Print() cil managed
  2:     {
  3:     }

while the code generated by the C# compiler is

  1:  .method public hidebysig virtual instance void Print() cil managed
  2:     {
  3:     }

Notice the extra hidebysig modifier on the method generated by the C# compiler?

According to the CLR ECMA Specifications (Section 15.4.2.2.) hidebysig - "specifies that the declared method hides all methods of the base class types that have a matching method signature; when omitted, the method should hide all methods of the same name, regardless of the signature." In C# and VB the signature of a method consists of the method name and its parameter types.

This is the root cause of the problem.

When the C# compiler tries to bind the Print(true) call it first has to do a member lookup for the method Print. The simplified process steps are (read Section 7.3 of the C# spec for more info):

Determine the list of all the methods named Print defined by MyClass and its base classes. While building this list, exclude all the methods that are marked override
Remove all the members that are hidden by other members
Return the list

Because the referenced library does not mark the Print() method as hidebysig the method will hide all the methods named Print defined on the Base class. And according to the member lookup algorithm they have to be excluded from the candidate set (step 2). This explains the error that the C# compiler gives.

So the behavior is by design. If you do want to be able to call both Print methods from C#, you have to write the VB code like this:

  1: Public MustInherit Class Derived
  2:     Inherits Base
  3: 
  4:     Public Overloads Overrides Sub Print()
  5:     End Sub
  6: End Class

By specifying both modifiers (Overloads Overrides) on the Print method you tell the VB compiler that the method Print overrides the base method but has to be considered as an overload to the rest of the Print methods defined on the base class.

Using the static type of a variable in a dynamic call

Alex Ghiondea - MSFT — Thu, 14 Jan 2010 00:02:00 GMT

As I said before, figuring out when the compiler will dispatch a call dynamically is simple: anytime the receiver or one of the arguments of a call is dynamic. And when using a variable of type dynamic means that the Runtime Binder will use the runtime type of the value stored in that variable and NOT it’s compile-time type. You can read more about compile time versus runtime type in my previous entry.

Let’s first figure out what is a scenario when the RuntimeBinder should use the compile time type of the variable instead of it’s runtime type.

Consider the code below:

  1: public class Base
  2: { 
  3:     public void Foo(string s) {}   
  4: }   
  5: public class Derived : Base   
  6: {   
  7:     public void Foo(int x) {}   
  8: }  
  9: 
 10: Base obj = new Derived();  
 11: dynamic d = 4;  
 12: 
 13: obj.Foo(d);

At line 11 we instantiate a new Derived class and stick it into a variable of type Base. From the compiler’s perspective, this means when doing overload resolution it should only look at the methods defined by the Base. With that logic, the only method that the compiler should consider for overload resolution is Foo(string).

Because this method call is dispatched dynamically, the RuntimeBinder MUST consider the same set of overloads. If the RuntimeBinder would have used the runtime-type for obj, the methods that would be considered when doing overload resolution would be Foo(string) and Foo(int) since the runtime-type of obj is Derived.

This would lead to some very confusing cases when you are expecting one method to be called and at runtime a different one gets called.

The same reasoning applies to passing arguments that are not typed dynamic to a method call that is dispatched dynamically.

To summarize, there are two cases when the static type of a variable is passed to the RuntimeBinder:

If the receiver of the call is not typed dynamic but at least one of its arguments is typed dynamic.
- We need to have at least a dynamic argument in the call in order to have the call dispatch dynamically

If any of the arguments to a dynamically dispatched method call are not typed as dynamic.

An example might explain this better:

int x=4;
dynamic d = new MyClass();
d.Foo(x);

Because x is not typed as dynamic, the compiler will pass the information about it’s static type to the RuntimeBinder

The compiler encodes the static type of a variable and passes that information to the RuntimeBinder by using the CallSite object we talked about here.

Feel free to post any questions you might have.

When does the compiler dispatch a call dynamically?

Alex Ghiondea - MSFT — Mon, 04 Jan 2010 20:18:00 GMT

There are 2 cases when a call will be dispatched dynamically:

When the receiver of the call is statically typed as dynamic
```
   1: dynamic d = new MyClass();
```
```
   2: d.Foo();
```

When any of the arguments to the call are statically typed as dynamic

   1: var o = new MyClass();

   2: dynamic d = 4;

   3: o.Bar(d);

By keeping the rules simple we hope to avoid cases where there is confusion about whether or not a call is dispatched dynamically.

Compile time type vs runtime type of a variable

Alex Ghiondea - MSFT — Wed, 20 May 2009 02:51:00 GMT

Let’s consider this code for a moment:

   1:  public abstract class Animal { }

2:

   3:  public class Tiger : Animal { }

4:

   5:  public class Elephant : Animal { }

6:

   7:  public class MyClass

   8:  {

   9:      public static void Main()

  10:      {

  11:          Animal a = new Tiger();

  12:      }

  13:  }

Now answer these two questions:

What is the compile time type of the variable a?
What is the runtime time of the variable a?

If your answer is:

Compile time type is Animal and runtime type is Tiger then you are right on the money!

Why is that?

Because, for the compiler, the type of the variable is the type you used to define it. In this case, your variable is defined as type Animal, which means that the compile time type of it is Animal.

However, you are assigning to that variable a new instance of type Tiger. This means that, when you are running the program, a memory location will be created to store a variable of type Tiger. Also, if you look at the definition for type Animal, you can see that the type is declared as Abstract and an abstract type cannot be instantiated.

Why is this important? Well, in C# 4.0, the Runtime Binder that we introduced uses the runtime type of variables instead of the compile time type when doing overload resolution.

How-To: Dynamic without dynamic

Alex Ghiondea - MSFT — Tue, 19 May 2009 02:53:00 GMT

I am sure that by now you all heard about the new C# 4.0 feature called dynamic. In short, dynamic is the new feature in C# 4.0 that allows you to defer member binding until runtime.

The way you use this feature is very straight forward. If you have a class C with a method M and you want to call the method M but defer the binding until runtime, you would write this:

   1:  dynamic d = new C();
   2:  d.M();

What happens is that the compiler will notice that you are trying to do a late-bound call and will generate some code behind the scenes that will capture all the necessary information to allow the late binding to succeed.

The information is captured inside a CallSite object, and this is what such an object contains:

The type of the operation you want to bind (method call, property set, etc)
Is the method you are calling static
The name of the method you want to call
The context where the call was made (the class that contains the call). This is used to determine if a call to a private method should be allowed
The type arguments of the method (if any)
The type of all the arguments for the method call

There is nothing stopping you from creating such a structure by yourself in your code. You would have to write something like this:

   1:  var callM = CallSite<Action<CallSite, object, object>>.Create(

   2:      new CSharpInvokeMemberBinder(

   3:          CSharpCallFlags.None,

   4:          "M",

   5:          typeof(Program),

   6:          null,

   7:          new CSharpArgumentInfo[] {

   8:                  new CSharpArgumentInfo(CSharpArgumentInfoFlags.None, null)

   9:          }

  10:      )

  11:  );

Besides all the information that is captured already, one interesting bit of information is decoded from using the Action delegate. By using Action we are specifying that we don’t care about the result of the operation (or that the return type of the method is void). If we did want to get back a result from the operation, we would have had to use Func instead of Action.

Now that all the necessary information is available inside the callM object we can execute the method using late binding. To do that, we simply do this:

   1:  object obj = new C();

   2:  callM.Target(callM, obj);

f you run this code you will be calling the method M using late binding. And that’s how you do dynamic without dynamic

C# 4.0 - Dynamic internals talk

Alex Ghiondea - MSFT — Tue, 07 Apr 2009 21:19:00 GMT

Yesterday I gave a talk to the Redmond .NET user group where I talked about the C# 4.0 dynamic feature. The talk focused on how the feature is implemented and how all the pieces go together.

About 30 people showed up and stayed for the 1 hour and 40 minutes of dynamic talk.

According to the feedback I got, people enjoyed the technical talk, and that made me feel good [:d].

I have attached the slide deck if you are interested.

Using Anonymous types to deserialize JSON data

Alex Ghiondea - MSFT — Tue, 23 Dec 2008 00:58:00 GMT

While I was playing around with deserializing objects written in JSON format, I noticed that I had to write a lot of classes that were used just to deserialize the JSON response. I noticed that I did not necessarily needed those classes, and that I often would just transfer data from those classes back into my own objects. Basically, I ended up with a lot of classes which were used just to get the JSON response into objects.

I started thinking about how I could leverage C# language features to accomplish the same goals. I this article I am going to show you how you can use the C# 3.0 anonymous types feature to deserialize JSON data back into objects. For parsing JSON and assigning values to my object I will use this JSON implementation.

C# 2.0

The JSON text that I am trying to parse is this:

string JSONText = "{Text:\"Hello World!!\", Status:\"Ok\"}";

In order to do this, I would have to create a class (with any name) that will have the two properties Text and Status:

class HelloWorldResponse
{
public string Text { get; set; }
public string Status { get; set; }
}

And now, in order to deserialize the data, I use the JSON serializer like so:

var x = js.Deserialize(new StringReader(JSONText), typeof(HelloWorldResponse)) as HelloWorldResponse;

C# 3.0

In C# 3.0 we introduced the notion of anonymous types - types that have no name that you can speak - that can have any shape you want. The main reason why they were introduced is to support LINQ, but they can be used in other way as well.

So, in C# 3.0 instead of writing my own classes, I decided to let the compiler do the work for me. What I will do is to create the anonymous types in the function that need that response. I will pass the anonymous type to the JSON deserializer and get back an object that contains an anonymous type populated with the data from the JSON string. To get from object to the strongly typed anonymous type, I will use a generic method that casts the object to the type of the anonymous type .

Here is the method that converts object to the anonymous type:

public static class TypeExtension
{
    public static T ToType<T>(this object o, T typeToCastTo)
    {
        return (T)o;
    }
}

This is a generic extension method that takes in two arguments: the object I am trying to convert and the type I am converting to. The compiler will do type inference on the argument going in, so if I pass in a variable of an anonymous type, it will figure out the unspeakable name for the anonymous type. Then, it just returns the result of the converson from the object to that type.

Then, I can just write the code like this:

var helloResponse = new { Text = string.Empty, Status = string.Empty };
var y = js.Deserialize(new StringReader(JSONText), helloResponse.GetType()).ToType(helloResponse);

And then, y will hold a reference to an anonymous type and I can use it to read the properties from the type.

The advantage that I am getting is not in the number of classes that I have to write - the compiler will generate the same number of classes* as I would have. The disadvantage to this solution is the fact that now I have type definitions inside methods, which can make it harder to debug/change. Also, if your internal classes map directly to the response you get as JSON, then you are probably better off using "real classes".

C# 4.0

In C# 4.0, with the introduction of dynamic, we can further simplify this code. In C# 4.0, I don't need the method that will convert from object to the anonymous type. I can just stick the object returned from the JSON deserializer into a dynamic and use dynamic dispatch to get to the members that I care about:

var helloResponse = new { Text = string.Empty, Status = string.Empty };
dynamic y = js.Deserialize(new StringReader(JSONText), helloResponse.GetType());

The disadvantage of this solution is that you will not have IntelliSense one you go dynamic, so any spelling mistake will not be caught by the compiler.

So here you go - 3 ways of doing the same thing, each with their pros and cons. I really like to C# 3.0/ C# 4.0 versions where you create the type "on the fly" and then you go ahead and use result. I still don't like the fact that I need to explicitly state what are the members on the type. I would just like to get "a" type back and then magically get just the members I care about. Well - we'll see :).

*the compiler will try to reuse similar anonymous types, so you might actually get fewer types

C# 4.0 language features at Seattle Code Camp

Alex Ghiondea - MSFT — Sat, 15 Nov 2008 23:08:00 GMT

I just came back from Seattle Code Camp where I gave a talk on C# 4.0. Seattle Code Camp is a community organized event where people meet and talk about code.

My presentation was about the new language features we are introducing in C# 4.0. I talked about C# dynamic, named and optional parameters and COM interop. People were very interested about what you can do with the dynamic feature (i.e. call into Pyhon) and very happy about the COM interop support we are adding (i.e. named and optional). I really enjoeyd talking to fellow coders, eating pizza and just beeing there. I will most likely come back next year!

But wait! - The camp is not over yet!!

If my talk made you think about dynamic languages, Sunday is a great time to learn more. There are some interesting talks about dynamic languages in the Van Gogh room the entire day.

And, if you like LINQ and want to learn more about it you should go see the talk that my colleague Marcelo is giving from 1:15 in the Al-Khwarismi room.

[Edit] Added the slides for the presentation to this post