Re: .NET Compatibility

RedLars wrote:
On 28 Feb, 14:52, Jeroen Mostert <jmost...@xxxxxxxxx> wrote:
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.


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.

--
J.
.

Relevant Pages

  • Re: VB.NET 2008 not backward compatable?
    ... It's pretty clear that applications compiled against a *newer* version of a library won't work with older versions. ... there are differences in the CLR which prevent execution of .NET 2.0+-based assemblies on the .NET 1.* CLR.) ... VB6-based applications didn't run on the VB5 runtime libraries too. ... But there is one significant difference: .NET 1.1-based applications will run on newer versions of the CLR, whereas an application developed using VB5 won't run on a system which provides the VB6 runtime files only. ...
    (microsoft.public.dotnet.languages.vb)
  • Re: Application Domains
    ... > I agree that this is how the CLR handles application domains since they act ... Although, at current date, applications still ... > But as you say Jon, if we want, we can start a second appdomain in our ... likely to be limited by physical memory than virtual memory though. ...
    (microsoft.public.dotnet.framework.clr)
  • Re: Gartner: Everything in Vista is based on .Net, ... ;)
    ... Hosting the CLR was a no-brainer. ... sense to rewrite SQL Server in .NET. ... that windows forms applications may never truly catch in. ...
    (borland.public.delphi.non-technical)
  • Re: D8 may be 32 bit only
    ... applications move to Win64 in the WOW64 sandbox, ... Given that scenario it means that the CLR _IS_ ... I suspected that the the Delphi IDE might run as a 32-bit app on WoW64, ... As for Yukon, the 64bit Yukon will use the native 64bit CLR for managed ...
    (borland.public.delphi.non-technical)
Loading