Re: .NET Compatibility

RedLars wrote:
What .NET version are completely compatible?

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).

What I mean is, at our company we have at least one appplication
developed in .NET 1.0 that does not work when using .NET 1.1 runtime.
The problem apparently lies with changes to an xml class. So in my
opinion it's not completely safe to run an .NET 1.0 application
using .NET 1.1 runtime. How big a problem is this?

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).

Is this a problem for applications built using .NET 1.1 and run with .NET
2.0 ?

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.

What about applications developed using .NET 2.0? Read that they
cannot run on previous runtime versions, so no danger of it using
version 1.0 or 1.1 I suppose. What about .NET 2.0 app on .NET 3.0 or
3.5 runtime? Any compatibility issues there?

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. :-)

--
J.
.

Relevant Pages

  • Re: .NET Compatibility
    ... The framework, on the other hand, is the combination of the runtime and the ... BCL and updated ... applications developed with BCL 1.0 and 1.1 so that we use the same ... clr version as when the software was original development and tested. ...
    (microsoft.public.dotnet.framework)
  • Re: Namenskonvention
    ... Meine Quellen beziehen sich die SSCLI und Erfahrungen mit o.g. ... Reflector der Original Framework Assemblies. ... manche Teile sind .NET spezifisch und fehlen in der SSCLI. ... Nichtsdestotrotz ist zumindest die BCL weitesgehend für 1.1 identisch. ...
    (microsoft.public.de.german.entwickler.dotnet.csharp)
  • Re: IE Hosts Windows Control
    ... statement in the "What's new in the .NET Framework 1.1" ... Internet-based Web page or Windows Forms assemblies ... could get my control to execute on a framework v1 sp1 ... >> assemblyName, String ...
    (microsoft.public.dotnet.security)
  • Re: Goodbye and Best Wishes
    ... an N+1 capable framework, you can't even display a nice dialog box to ... > "When you choose to take advantage of features available in a newer ... with some assemblies coming from version n and some ... of an assembly compiled with an N+1 compiler to use an N framework, ...
    (borland.public.delphi.non-technical)
  • Re: God I Love Delphi7
    ... Windows Forms are extremely easy to use. ... Where do you put those assemblies on ... application config files shoule be placed in your app directory. ... know what version of an assembly to use and what framework it needs. ...
    (borland.public.delphi.non-technical)
Loading