Migrate to .Net 4.0 with new feature In Proc SxS

.Net framework is constantly upgrading to its subsequent versions starting from 1.0 to latest 4.0 version. The versions were released in a way that I could provide maximum support for libraries with a powerful run time. After release of .net 2.0 version other release of CLR was layerCaked on the existing framework. The term “layercake” model is used for these releases – in which version 3.0 added functionality on top of version 2.0, and version 3.5 on top of 3.0, without changing much functionality underneath.


The .Net 4.0 was the major release keeping in mind to cover all the missing support in the earlier versions. The problem that was faced at the earlier releases was because of installation of new release over the existing one. All the office application start using the latest installed version rather than using the existing one. so the plugins created on earlier framework start causing the problem since the change in runtime was seems to un-supportive to the code written in the old framework. Main problem identified was the due to change in the Thread model from 1.1 to 2.0 so the application created in 1.1 version causing the problem of Racing conditions as the Thread starts too early in the 2.0.

Threading problem was one of them that causing the problem after installing the latest version. But this problem is solved with the release of .Net 4.0. Framework supports the In process side by side execution of all the runtime that needed by the host process(Here host application is referred to the Office application e.g. Excel). So the installing .Net 4.0 version doesn’t make this runtime as default but it keeps the older version in memory so that older version plugins or libraries don’t start giving up.


The diagram provides an introduction to in-process side by side. In-proc SxS(In Process Sided by Side Execution) is an important part of keeping compatibility as the new versions change to support evolutionary needs, this is the best effort made by the Microsoft to provide highly backward compatibility.
The very common scenario that can be seen is both CLR 2.0 (.NET v2.0, v3.5 or v3.5) and CLR 4 installed. In this scenario, a managed application compiled against CLR 2.0 needs to run against CLR 4 and also needs to activate Managed COM Components compiled against CLR 4 side by side with Managed COM Components compiled against CLR 2.0 (or previous version). In this situation, an application configuration file needs to be included in the same directory of the managed application (EXE) with the following entry:
<supportedRuntime version="v4.0.XXXXX" />
<supportedRuntime version="v2.0.50727" />
<rollForward enabled="false" />
There can be many scenarios when the In-Proc SxS comes into picture with .Net 4.0 Common In Process Scenario and configurations are well explained here in below MSDN blog:

I came to write this post considering those people who are working on .Net 2.0 and looking for upgrading to the latest version. With the new features the .Net 4.0 would be the best version to choose for upgrade with its backward compatibility support. Thanks for you time reading this post Smile . please leave comments with your views.


  1. Nice blog man... It will be very helpful for those still using older versions of framework. I should be like a basis for those people doing upgrade to their version.

  2. nice blog.........

    ASP.NET lovers check this URL:

    This blog describes new features of ASP.NET 4.0(Session State Compression,ViewState,URL Routing,
    Output Cache Extesibility, diff between ASP.NET 4.0 and its previous version) and the BASICS of
    ASP.NET(Common Language Runtime,Common Type System,Common Language Specification, Class Library,