The .NET framework is a bit confusing until you get your head round the components of it, and the way that Microsoft name things.
.NET has a thing called the common language runtime (CLR). (This is the .NET equivalent of the Java Runtime). Different versions are essentially different VMs, and can coexist. The CLR runs code that is an Intermediate Language (IL) (aka the Common Intermediate Language (CIL)). Whatever code you write in C# or VB.NET actually only gets partially compiled into IL code. It’s a lot like Java Bytecode.
The Base Classes are the library of DLLs for the framework (and are sometimes incorrectly referred to as the framework). Think of it as Win32 for .NET. These constitute the .NET API – and have different versions too. A different version of the base classes, though, does not mean a different CLR – for example, frameworks version 2, 3 and 3.5 all use the same CLR, but present a different external API and have different language features. Indeed, the base classes of framework version 3.5 are a superset of version 3, which are a superset of 2. This means framework 2 code will run on machines with the 3.5 installed.
The languages have different versions too, and this is where things start to get confusing. The different language versions have different compilers, which emit backward compatible IL. This is to be expected since there is no new version of the CLR. In plain terms this means that all the new language features can be used with older projects. E.g. C# 3.0 code can run on the .NET 2 Framework, provided you haven’t used any of the libraries that are part of a later framework. The C# 3.0 code will be partially compiled into the same version of IL code as your C# 2.0 code, so the only problems come if you are using libraries that aren’t part of that .NET Framework.
(Note to self – must remember – C# version is independent of Framework version)
So why would you want to use C# 3.0 over C# 2.0? Well, the language adds a number of new features too – such as automatic properties, relaxed delegates, object initialisers, type inference, anonymous types, extension methods, lambdas and partial methods.
Hopefully this chart might explain things a bit. I’m pretty sure it’s right, although I’m recreating it from memory and can’t entirely remember…
|
|
Framework Version 1.1 |
Framework Version 2.0 |
Framework Version 3 |
Framework Version 3.5 |
|
CLR |
1.1 |
2.0 |
2.0 |
2.0 |
|
Library versions |
1.1 |
2.0 |
3.0 (including 2.0 sp1) |
3.5 (including 2.0 sp1 & 3.0 sp1) |
Similar chart here:
http://www.leonmeijer.nl/archive/2007/06/11/50.aspx
…though the Microsoft guy who presented to me didn’t say anything about a CLR 3.0. I suppose there may be one which is backwardly compatibile?
Andy Burns' Blog 
Thanks for the links.
To be precise:
1. all your references to 2.0 and 3.0 under 3.5, should be 2.0 SP1 and 3.0 SP1.
2. The compiler verison used is irrelevant to the Framework version. It is driven from the IDE: if it is VS2005, then it is C# 2.0. If it is VS2008, then it is C# 3.0
No problem – thanks for the presentation, it was interesting. Sorry it took so long to actually get to blogging about it!
Yes, forgot about the ‘SP1’ part – fixed. And fair point about the compiler version. I was just interested that you could write code in Visual Studio 2008 using C# 3.0 and then run it in the CLR 2.0 (if I understood correctly). That’s neat!