.net - Clarification on in process side by side execution -

.net - Clarification on in process side by side execution -

this extract this msdn article:

targeting , running apps older versions

the .net framework versions 2.0, 3.0, , 3.5 built same version of clr (clr 2.0). these versions represent successive layers of single installation. each version built incrementally on top of before versions. not possible run versions 2.0, 3.0, , 3.5 side side on computer. when install version 3.5, 2.0 , 3.0 layers automatically, , apps built versions 2.0, 3.0, , 3.5 can run on version 3.5. however, .net framework 4 ends layering approach, apps built 2.0. 3.0, or 3.5 not work on version 4 or later. starting .net framework 4, can utilize in-process side-by-side hosting run multiple versions of clr in single process.

from above paragraph:

it not possible run versions 2.0, 3.0, , 3.5 side side on computer.

this certainly not true it? can have applications using 2.0 , 3.5 run on same machine.

starting .net framework 4, can utilize in-process side-by-side hosting run multiple versions of clr in single process.

this biggest problem. can confirm, 1 time , all, whether in process side side execution, introduced in .net 4.0, applicable .net processes or native com applications using managed com add together ins? several msdn articles create generic statement seen above, com add together ins. 1 it?

.net 2.0 brand-new version of clr not compatible either of older versions, .net 1.0 or 1.1. however, .net 3.0 , 3.5 extensions built on top of .net 2.0 clr. added features (e.g., wpf , linq) not there in 2.0, , fixed bugs in clr, strictly designed supersets. in sense, not possible have .net 2.0, 3.0, , 3.5 installed side-by-side on same machine. there no .net 3.0/3.5 without .net 2.0. latest version of install replace other. apps target older version go on run on newer version because required pieces still there.

so statement documentation:

it not possible run versions 2.0, 3.0, , 3.5 side side on computer.

is true. interpretation of incorrect. can have different applications installed target 2.0 , 3.5, , go on run. they'll utilize same clr.

as sec question, regarding side-by-side execution, all versions of .net framework have supported side-by-side hosting managed applications. have .net 1.0, 1.1, , 2.0 installed simultaneously, , applications whichever version of framework targeted.

the problems started when had add-ins targeted different version of clr host application. these either ran on wrong/unexpected version of clr , had unexpected behavior (i.e. bugs), or refused load altogether.

this problem punted versions 3.0 , 3.5 because, explained above, built on top of .net 2.0 clr—the so-called "layer cake" model. version 4.0 introduced in process side-by-side execution, allows multiple versions of clr hosted in single process. way, app gets version of clr targets , add-ins hosts version(s) of clr request in app.config file(s). inproc sxs available all processes load clr. confusion in reading documentation stems fact com add-ins mutual , hence subject of articles. mutual utilize case native applications consume multiple managed add-ins, each targeting different versions of clr.

this article msdn magazine has interesting , relevant tidbits.

oh, , way, .net 4.5 uses totally different model yet. in-place replacement of .net 4.0 dlls. whole other answer.

.net .net-4.0 side-by-side