Reply to thread

Message: [QUOTE="Jeroen Mostert, post: 11770061"] The important factor is the runtime. There are three "main" versions now: v1.0.3705, usually called "1.0", v1.1.4322, usually called "1.1", and v2.0.50727, usually called "2.0". The framework, on the other hand, is the combination of the runtime and the base class libraries. The .NET Framework 1.0 is the combination of the v1.0.3705 runtime with the 1.0 BCL, 1.1 is v1.1.4322 with the 1.1 BCL, and 2.0 is v2.0.50727 with the 2.0 BCL. So far, so good. From this point on, however, things start to diverge. .NET 3.0 is the v2.0.50727 runtime with the 3.0 BCL (which is the 2.0 BCL with additional assemblies) while .NET 3.5 is the v2.0.50727 runtime with the 3.5 BCL (which, indeed, is the 3.0 BCL with additional assemblies) and updated compilers to support the new languages (C# 3 being the most prominent). Usually, not very. There are incompatibilities, but they're minor, and usually well-documented. If you're concerned, it's always possible to force the code to run on the exact version of the framework it needs, through its ..config file. Microsoft tries its best to break things as little as possible, and when it does break you can always force use of the "correct" runtime. Of course, a better long-term solution is to future-proof your application. Usually, the changes are fixes, and there is a better way of doing the same thing even in the older runtime. OK, if you can bear with me, there's one more small detail I haven't mentioned: service packs. These only update the build number, which you can check with mscorlib.dll in the framework directories: .NET 2.0 RTM is 2.0.50727.42, .NET 2.0 SP1 is 2.0.50727.1433. These are only intended to fix things that really can't wait for a new runtime version, and they are intended to be good and necessary for every application using the existing runtime (so you can't opt out). Occasionally. The changes between 1.x and 2.0 are much bigger, from a runtime perspective (assembly formats, finalization, garbage collection, app domain handling, a whole lot got upgraded), even though most changes do not visibly affect applications. The most obvious change for developers is the fact that in 1.x, unhandled exceptions would be silently swallowed. In 2.0, unhandled exceptions terminate the application. This is generally a good thing and an opportunity to fix a broken application. There is a switch to make 2.0 behave like 1.x in this regard, however. If you've followed my little lecture so far, you should realize that there are none whatsoever, because there are no 3.0 or 3.5 runtimes -- .NET Framework 2.0, 3.0 and 3.5 all share the same runtime, and they have the 2.0 BCL in common. (Disclaimer: I believe things are slightly different for the ..NET Compact Framework, which does have a separate 3.5 runtime -- don't ask me for details, though.) In fact, 2.0 applications can reference and use 3.0 and 3.5 assemblies just fine (I recently wrote a WCF application with VS 2005). So until CLR 3 comes out, we're good. :-) [/QUOTE]

Verification