Testing compatibility for Whidbey/Everett

Clarification via EricGu...having an
Everett assembly reference a Whidbey assembly is not a supported scenario, plus generic
metadata will cause weird things to happen.  
Thanks Eric :) 

Someone sent a question recently to an internal alias so I thought I would share.
The question was what will happen when a C# V1 component consumes a C# V2 component
that exposes a generic class.  First some background information, there are two
types of compatibility, backward compatibility and forward compatibility. 

  • Backward compatibility refers to a future version of a product, like Whidbey, supporting
    already existing functionality like something found in .
  • Forward compatibility refers to an older product, like Everett, being able to
    support a new feature like generics.

As you can imagine, it's easier to add backward compatibility since it is a known thing. 
Designing for forward compatibility can be more difficult as it is an unknown thing. 
The goal of C# Whidbey is geared more towards backward compatibility so that if you
write a component today for version 1.x, your component will "just work" in C# Whidbey. 

I decided to test what forward compatibility will work with the current Tech
preview for a VS Whidbey component to be used in VS 2003. To test forward
compatibility, I created a simple generic class with two static methods.  The
first method returns a generic collection, the second returns a non-generic collection.

V2 Code

public class GenericClass



     public static List<int>


l = new List<int>();


           return l;



     public static ArrayList ReturnNonGeneric()


           ArrayList ar
= new ArrayList();


           return ar;



I added a reference to the
GenericClass in VS 2003. Using IntelliSense, the only method that is
available to execute is GenericClass.ReturnNonGeneric() since VS 2003 doesn't
understand a non-generic type.  Since VS 2003 doesn't understand generic
types it can't call the ReturnGeneric() method.

Comments (3)
  1. What if, from Everett, you attempted to call a Whidbey method that does not expose generics in its signature (and would therefore be visible) but that uses generics internally in it’s implementation?

    Would this bind at compile-time but fail at run-time with some exception?

  2. Correct, that was my personal experience…the code compiled without errors but threw an exception at run-time. There may be occasions where Everett code could call Whidbey code without run-time errors but we’re not explicitly designing for this type of compatibility (forward). You could of course take the whidbey code base and compile it against the 1.1 version of the framework.

Comments are closed.

Skip to main content