.NET Compatibility

[RedLars]

What .NET version are completely compatible?

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? Is this a problem
for applications built using .NET 1.1 and run with .NET 2.0 ?

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?

 

[Jeroen Mostert]

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.

 

[RedLars]

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.

The solution we are think about is using an app.config file for all
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.
Obviously it would be nice to 'upgrade' the code so that it runs on
all versions of the clr, but this requires time for re-implementing
and re-testing an unknown amount of code.

Reading about .NET compatibility yesterday and found this line very
interesting, "Applications created with version 2.0 will not run on
earlier versions of the .NET Framework." [1]. This means that an
application developed using BCL 2.0 does not need an app.config file
since it only has one clr version to select. Or am I jumping to a
conclussion?

[1] - http://msdn2.microsoft.com/en-us/library/47a587hk.aspx

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.

Excellent response, again

 

[Jeroen Mostert]

The solution we are think about is using an app.config file for all
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.

This is a fine solution; the option's there for a reason.

Obviously it would be nice to 'upgrade' the code so that it runs on
all versions of the clr, but this requires time for re-implementing
and re-testing an unknown amount of code.

If you're fairly sure you won't need to change the application any time
soon, this is good. Otherwise, when a modification is needed, you might as
well spend some extra time to bring the code up to 2.0 at least. This will
bring stability and performance improvements as well.

Reading about .NET compatibility yesterday and found this line very
interesting, "Applications created with version 2.0 will not run on
earlier versions of the .NET Framework." [1]. This means that an
application developed using BCL 2.0 does not need an app.config file
since it only has one clr version to select. Or am I jumping to a
conclussion?

Yes, you are. As soon as CLR 3.0 comes out (this might still be a few years
off) 2.0 applications will find themselves in the same predicaments as 1.0
applications are in now.

*Currently*, you won't need to fix the runtime, because there is no runtime
more recent than 2.0. But this won't stay that way forever. If you are again
sure that the applications you've developed will not need to undergo major
maintenance or require new features any time soon, you may as well fix the
runtime now.