Reply to: Dotnet backward compatible?

[xoggoth]

Lots of sorts of things one would do with a major busines but with what is basically a retirement hobby that brings in about 2k a year not really economic.

Anyway, having done uninstall and reinstall again what happens (on this machine anyway) is that installing 3.5 also installs service packs for 3.0 and 2.0. So progs like mine designed for those versions find the right registry entries and instal seemlessly. Which is nice.

[ASB]

Removed dotnet 2.0 redistributable on XP machine and checked my prog crashed. Then installed 3.5 and reinstalled my prog. It did not attempt to reinstal 2.0 and it all seems to works fine. Ta for all the unput.

PS Although it occurs to to me that not attempting to instal 2.0 could be just due to a registry entry left behind. Without dozens of different machines to test on it's hard to be sure of anything.

All you need is 400 VPC sandbox and a couple of years and you can be reasonably sure......

As .NET becomes more integrated as part of the OS these issues will of course all be resolved.

Well stone me, this pig has just flown past my office window.....

[xoggoth]

Removed dotnet 2.0 redistributable on XP machine and checked my prog crashed. Then installed 3.5 and reinstalled my prog. It did not attempt to reinstal 2.0 and it all seems to works fine. Ta for all the unput.

PS Although it occurs to to me that not attempting to instal 2.0 could be just due to a registry entry left behind. Without dozens of different machines to test on it's hard to be sure of anything.

[Durbs]

I've never managed to get any serious application built for 1.1 to work on a machine that only has 2.0 installed (too many breaking changes in 2.0).

Yes, 1.1 and 2.0 are pretty different, 2.0 and 3.5 are not. You normally see both installed on the box and choose to target 1.1 or 2.0 within IIS for the app (assuming web app). They are separate installers, separate apps.

1.0 and 1.1 developed apps use 1.1
2.0 and 3.5 developed apps use 2.0 (even if the 3.5 framework is installed, it will show as 2.0)

You generally wont see 1.0 or 3.0 apps though as it was not really used.

[ASB]

IIRC VS 2005 compiles always against 2.0?

VS 2008 allows you to select runtime 2.0, 3.0 or 3.5

If you have a machine with 3.0 or 3.5 installed and no 2.0, your project compiled against 2.0 in VS.NET 2005 should run fine.

1) VS2005/2.0 Probably, but not as simple as that. It was entirely possible to download and use 3.0 or 3.5 (maybe even 4.0 though by this time we are well into later VS of course). However, can't remember all the details of how it was achieved but there was a certain amount of black magic involved. However, in practice it would be unlikely that it was anything other than 2.0.

2) Yes, however it doesn't guarantee no problems of course (though strictly this is the case with anything other than the exact framework it was compiled with of course). However I believe there are potential issues with 2.0 and a later version also installed. So called side by side versioning. I think there are cases where issues can be found if external strong named assemblies in the GAC are used (or something along those lines).

[DimPrawn]

IIRC VS 2005 compiles always against 2.0?

VS 2008 allows you to select runtime 2.0, 3.0 or 3.5

If you have a machine with 3.0 or 3.5 installed and no 2.0, your project compiled against 2.0 in VS.NET 2005 should run fine.

[xoggoth]

Ta for further comments although does not seem to be entire agreement. My progs are not as ancient as 1.1 fortunately, it's 2.something.

Not entirely sure what "compiled against" is about, it's compiled with whatever Visual Studio 2005 with all updates is using. Certainly no probs on Vista or win 7 related to .net version.

Maybe I will clear .net off a machine, instal dotnetfx 3 and see what happens when I try and instal the prog.

PS I see from ASB's link that the dotnet version for "bootstrapper" is in the vbproj xml but that sounds like a packager thing.

[ASB]

Must say I'm with DP. Install the right runtime. But there are some ways and means of resolving some of the issues in some cases (is that wooly enough?)

supportedRuntime in the configuration file
assemblyBinding can also be used in the configuration file

This thread might just prove useful, or at least a start to what you might want to look for:-

http://stackoverflow.com/questions/2...untime-version

But to reinforce what DP said you could be getting into a whole heap of trouble quickly. Certainly there are breaking changes (e.g. one of the old configuration methods was deprecated between 1.1 and 2.0. This now gives a warning should you be compiling code that uses it, but just throws an exception if it's called.)

You might be able to do something with machine polices to allow redirection.

Edit: Forgot this link:-

http://msdn.microsoft.com/en-us/library/9w519wzk.aspx

[gadgetman]

As I tried to explain, 1.0 and 1.1 and 2.0 are all distinct, non-backward compatible frameworks. 3.0 and 3.5 are based on the 2.0X CLR with added extras.

If you program is compiled against 1.1 and the target machine has 1.0, 2.0, 3.0 or 3.5 installed it won't work.

To be honest, there is no excuse for not bringing your software up to the latest version of the framework.

It's not MY software!

[DimPrawn]

Are you sure?

From http://msdn.microsoft.com/en-us/library/47a587hk.aspx...

Maybe I'm wrong about the 1.0 and 1.1 versions, but I've never managed to get any serious application built for 1.1 to work on a machine that only has 2.0 installed (too many breaking changes in 2.0).

All this is sorted out by any decent installer program (e.g. Wise or InstallShield), which will detect what frameworks are already installed and silently install the runtime for the one that your application is compiled against.

[voodooflux]

If you program is compiled against 1.1 and the target machine has 1.0, 2.0, 3.0 or 3.5 installed it won't work.

Are you sure?

From http://msdn.microsoft.com/en-us/library/47a587hk.aspx...

The degree of .NET Framework support for backward and forward compatibility is version-specific. The .NET Framework supports both backward and forward compatibility for applications created using version 1.1 only. It does not support forward compatibility in applications created using version 2.0. In the context of the .NET Framework, backward compatibility means that an application created using an early version of the .NET Framework will run on a later version. Conversely, forward compatibility means that an application created using a later version of the .NET Framework will run on an earlier version.

The .NET Framework provides a high degree of support for backward compatibility. For example, most applications created using version 1.0 will run on version 1.1 and applications using version 1.1 will run on version 2.0. The .NET Framework also supports forward compatibility for version 1.1 only. However, for forward compatibility you might need to modify an application so that the application runs as expected. Applications created with version 2.0 will not run on earlier versions of the .NET Framework. For both backward and forward compatibility, a change to the .NET Framework that helps improve security, correctness, or functionality might also raise compatibility issues.

[DimPrawn]

Here's a recent example I came across from Microsoft(!)

When you try to install it it says "This app requires .NET v1.1.4322" and refuses to work even if .NET V 2 or higher is installed.

As I tried to explain, 1.0 and 1.1 and 2.0 are all distinct, non-backward compatible frameworks. 3.0 and 3.5 are based on the 2.0 CLR with added extras.

If you program is compiled against 1.1 and the target machine has 1.0, 2.0, 3.0 or 3.5 installed it won't work.

To be honest, there is no excuse for not bringing your software up to the latest version of the framework.

[gadgetman]

Here's a recent example I came across from Microsoft(!)

When you try to install it it says "This app requires .NET v1.1.4322" and refuses to work even if .NET V 2 or higher is installed.

[xoggoth]

Cheers dim.

When you say it will check the version installed, do you mean you are assuming the program installation will do it, or that any dotnetfx installation launched by the program will do it?

Wil have a decko at that xenocode. Looks complicated on quick scan.

[DimPrawn]

Hi Xog.

The framework versions are:

1.0 (very old)
1.1
2.0 (lots of new stuff)
3.0 (this is the 2.0 version with new features such as WCF, WPF, etc).
3.5 (this is just the 3.0 version with some new API's and LINQ, ASP.NET Ajax etc ).

When you compile your application in VS.NET you target a particular version (e.g. 2.0 or 3.5).

When you create you deployment package (using VS.NET, or a 3rd party deployment package), it will check the version installed, and if it requires a newer version, run the installer for that version).

Another option is to use something like Xenocode. This makes life a lot easier!

http://www.xenocode.com/
http://www.xenocode.com/Technology/

No more missing DLL's, framework conflicts, security issues etc.

PS you need the Xenocode Virtual Application Studio ISV Edition

http://www.componentsource.com/produ...rices-gbp.html