How long will my .NET 2.0 application continue to work?

Question

Each version of Microsoft's .NET frameworks have a limited support lifetime, e.g.:

• support for .NET Framework 1.1 ended 09/09/2005
• support for .NET Framework 2.0 ended 12/01/2010
• support for .NET Framework 3.0 ended 12/07/2011

I own an application from 2004 that was written with .NET Framework 1.1. If you try to install the .NET Framework version 1.1 on a modern Windows 7 64-bit machine you will get an error - it just won't work. A program written in 2006 is no longer usable; you might as well throw it away.

Does this mean that a program that I write in .NET 3.5 today will, at some point in the future, just be unusable?

Microsoft went to great lengths with the Windows API to maintain backwards compatibility. A program written 18 years ago (for Win32 or Win32s) will still run on Windows of today. (I know - I own one. It originally ran on Windows 3.1 and still runs on Windows 7 64-bit.)

A native program that I write today will still work 18 years from now (likely). But it seems that a .NET program I write today has no assurance that it will continue to function.

Is there any compatibility commitments from Microsoft regarding .NET framework 2.0 or later? I know .NET Framework 1/1.1 was an ugly stepchild; that .NET framework 2.0 broke compatibility with 1.1; but every framework since 2.0 has been compatible with 2.0.

Is there a note somewhere that if I write a managed application with .NET 2.0 or newer, that it should continue to run on Windows 8, Windows 9, Windows 10, etc.?

---

The Case of the .NET Framework 1.1 error

Spying on the program using Process Explorer, I found the .NET object it's trying, and failing, to create:

It's class:

• clsid: {60EBA0BC-D6AF-41C2-9584-D48D3DA39999}
• progid: Engine.Factory

So I created a little test application to see if I could create the same COM object:

const Guid CLSID_EngineFactory = '{60EBA0BC-D6AF-41C2-9584-D48D3DA39999}';

IUnknown unk = CoCreateIntance(CLSID_EngineFactory, null, CLSCTX_INPROC_SERVER | CLSCTX_LOCAL_SERVER, IUnknown);

Which fails for me too. I find the registration details in the registry:

HKEY_CLASSES_ROOT\Wow6432Node\CLSID
   {60EBA0BC-D6AF-41C2-9584-D48D3DA39999}
      InprocServer32
            (Default)       mscoree.dll
            Assembly        mcengr, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null
            Class           Engine.Factory
            RuntimeVersion  v1.1.4322
            ThreadingModel  Both

If the program should run with .NET framework 4 installed, then I suppose I can blame the application's installer.

That very well may be the answer to my question:

• while .NET Framework 1.1 is no longer supported,
• .NET Framework 1.1 is still supported

I just assumed that both of those statements couldn't be true at the same time.

Answer 1

Most .NET 1.1 programs should work fine on .NET 2 and even .NET 4 runtimes. The framework has the capability in place of running older versions. The only exceptions are if the application makes use of something that changed between framework versions (so called breaking changes).

Having said that, I don't understand why .NET 2 is not supported as long as .NET 3 and 3.5, since 3 and 3.5 are supersets of .NET 2.

So the answer is, your applications should keep working for a long time to come, unless you happen to have some code that is dependent upon a breaking change.

From the horses mouth, Version Compatibility in the .NET Framework (MSDN):

The .NET Framework 4 is backward-compatible with applications that were built with the .NET Framework versions 1.1, 2.0, 3.0, and 3.5. In other words, applications and components built with previous versions of the .NET Framework will work on the .NET Framework 4.

However, in practice, this compatibility can be broken by seemingly inconsequential changes in the .NET Framework and changes in programming techniques. For example, performance improvements in the .NET Framework 4 can expose a race condition that did not occur on earlier versions. Similarly, using a hard-coded path to .NET Framework assemblies, performing an equality comparison with a particular version of the .NET Framework, and getting the value of a private field by using reflection are not backward-compatible practices. In addition, each version of the .NET Framework includes bug fixes and security-related changes that can affect the compatibility of some applications and components.