I do not understand how this works - I am using VS2008 and using 3.0 language features like the var keyword.

Yet I can compile and run against a 2.0 framework version

How is that possible?

EDIT: Is there a website which defines the CLR, Framework and language features and backward compatability - I am quite confused by all that

+3  A: 

The reason why is that the binary produced from the C# compiler using most 3.0 features is compatible with the 2.0 runtime. The CLR doesn't care what language or version of the language that you used, only that the binary is compatible with it's specifications.

The var keyword is the simplest case because it simply infers the type of a local variable. The compiler then writes the explicit type out to the binary. So the following 2 lines are equivalent as far as the emitted IL

var x = 42;
int x = 42;
Isn't it _all_ 3.0 features that's compatible with the 2.0 runtime?
Rune FS
@Run FS, strictly speaking no. C# expression trees are not compatible with 2.0 RTM because of several bugs which exist in the CLR. They are compatible with 2.0 SP1 and above.
+2  A: 

var, for instance, is a compile-time feature and is in no way tied to any particular version framework (aside from the fact that it was introduced with Visual Studio 2008).

Another compile-time feature that works across framework versions (slightly to my own surprise) is optional and named arguments in Visual Studio 2010. But it makes sense that the compiler can easily generate whichever methods are necessary.

Mark Rushakoff

var is purely compiler feature, it doesn't require any runtime specific support


None of the new features in C# 3.0 required any changes to the underlying .NET runtime: things like the var keyword, extension methods and automatic properties result in code that you could have written by hand in 2.0.

In other words, the var keyword is syntactic sugar.

Tim Robinson
While they don't require CLR changes, some features do require framework support - expression trees being the most obvious candidates.
Jon Skeet

The framework version only determines which library classes & methods you can access. var is an entirely compile-time concept. These two lines compile to exactly the same IL:

var str = String.Empty;
string str = String.Empty;

Similarly, automatic properties are entirely compile-time. This:

private string <>SomeRandomName;
public string Prop {
    get { return <>SomeRandomName; }
    set { <>SomeRandomName = value; }

and this:

public string Prop { get; set; }

produce exactly the same IL (modulo variable names & attribute decorations).

These features are not dependent on the classes and methods available in the mscorlib assembly

+7  A: 

Some language features are just the compiler being smart - var being one of them. The compiled code has no trace of the fact that the variable was declared via var.

Other features (e.g. extension methods) require support from the framework. Extension methods are recognised and advertised via ExtensionAttribute. Likewise expression trees require the Expression class and its subclasses.

Some other features require CLR support too - generics in C# 2 being the most obvious example. None of the features in C# 3 fully require CLR support; .NET 3.5 shipped with a service pack to the CLR, but no major changes. I suspect there are a few corner cases where the v2 CLR would have had problems with some expression trees before. (I think DynamicMethod changed a little internally, although I can't remember the details.) There may be some verifiability tweaks too.

I have an article which describes which features in C# 3 can be used when targeting .NET 2. I'll expand this to include C# 4 soon.

Jon Skeet
There is an issue with the 2.0RTM CLR which prevents it from properly processing C# expression trees (fixed in CLR 2.0SP1). It's hard to hit though because C# expression trees require System.Core whose installer requires CLR 2.0SP1.
Quote: NET 3.5 shipped with a service pack to the CLR, but no major changes - So you can use LINQ features (bought out on 3.5) on a 2.0 framewaork CLR?
@ChloeRadshaw: Yes... although you'll need library support. LINQBridge works as LINQ to Objects for .NET 2.0; some people have reported success using the Mono implementation of expression trees against .NET 2.0SP1 (which includes CLR 2.0SP1). Again, some minor changes in the CLR could be relevant in *some* situations when running against *vanilla* 2.0 CLR... but I suspect those would affect out-of-process execution rather than LINQ to Objects. See JaredPar's comment.
Jon Skeet

The short answer is that the .NET 3.5 features are all things that can be translated to 2.0 constructs by the compiler. There wasn't really anything changed in the framework itself, the compiler just learned some new tricks.

@Telos: Plenty changed in the *framework* (expression trees, new classes like System.Linq.Enumerable) but little changed in the CLR.
Jon Skeet
Hey, I said "short answer." ;)