Running .NET versions 2.0 and 3.x on the same computer

Question

This is an extract from this MSDN article:

Targeting and running apps for older versions

The .NET Framework versions 2.0, 3.0, and 3.5 are built with the same version of the CLR (CLR 2.0). These versions represent successive layers of a single installation. Each version is built incrementally on top of the earlier versions. It is not possible to run versions 2.0, 3.0, and 3.5 side by side on a computer. When you install version 3.5, you get the 2.0 and 3.0 layers automatically, and apps that were built for versions 2.0, 3.0, and 3.5 can all run on version 3.5. However, the .NET Framework 4 ends this layering approach, so apps built for 2.0. 3.0, or 3.5 will not work on version 4 or later. Starting with the .NET Framework 4, you can use in-process side-by-side hosting to run multiple versions of the CLR in a single process.

From the above paragraph:

It is not possible to run versions 2.0, 3.0, and 3.5 side by side on a computer.

This is surely not true is it? I can definitely have applications using 2.0 and 3.5 run on the same machine.

Starting with the .NET Framework 4, you can use in-process side-by-side hosting to run multiple versions of the CLR in a single process.

This is my biggest problem. Can someone confirm, once and for all, whether in process side by side execution, introduced in .net 4.0, is applicable for all .net processes or just native COM applications using managed COM add ins? Several MSDN articles make a generic statement as seen above, some say its only for COM add ins. So which one is it?

Answer 1

.NET 2.0 was a brand-new version of the CLR that was not compatible with either of the older versions, .NET 1.0 or 1.1. However, .NET 3.0 and 3.5 were extensions built on top of the .NET 2.0 CLR. They added features (e.g., WPF and LINQ) that were not there in 2.0, and fixed bugs in the CLR, but they were strictly designed as supersets. In that sense, it is not possible to have .NET 2.0, 3.0, and 3.5 installed side-by-side on the same machine. There is no .NET 3.0/3.5 without .NET 2.0. The latest version of those that you install will effectively replace the other. Apps that target an older version will continue to run on a newer version because all the required pieces are still there.

So the statement from the documentation:

It is not possible to run versions 2.0, 3.0, and 3.5 side by side on a computer.

is true. Your interpretation of that is incorrect. You certainly can have different applications installed that target 2.0 and 3.5, and they will continue to run. But they'll all use the same CLR.

As for your second question, regarding side-by-side execution, all versions of the .NET Framework have supported side-by-side hosting for managed applications. You could have .NET 1.0, 1.1, and 2.0 all installed simultaneously, and applications would get whichever version of the framework they targeted.

The problems only started when you had add-ins that targeted a different version of the CLR than the host application. These either ran on the wrong/unexpected version of the CLR and had unexpected behavior (i.e. bugs), or they refused to load altogether.

This problem was punted for versions 3.0 and 3.5 because, as I explained above, they built on top of the .NET 2.0 CLR—the so-called "layer cake" model. Version 4.0 introduced in process side-by-side execution, which allows multiple versions of the CLR to be hosted in a single process. That way, the app gets the version of the CLR it targets and any add-ins it hosts will get the version(s) of the CLR that they request in their App.config file(s). InProc SxS is available for all processes that load the CLR. Your confusion in reading the documentation probably stems from the fact that COM add-ins are the most common and are therefore the subject of most articles. Another common use case is native applications that consume multiple managed add-ins, each targeting different versions of the CLR.

This article from the MSDN Magazine has some interesting and relevant tidbits.

Oh, and by the way, .NET 4.5 uses a totally different model yet. It is actually an in-place replacement of the .NET 4.0 DLLs. But that is a whole other answer.