As we built the .NET Framework 4, one of the more difficult problems we faced was maintaining compatibility with previous releases while still adding new features and functionality. We followed strict processes requiring approval for any changes that might introduce compatibility issues—most were rejected—and ran a compatibility lab with hundreds of real applications to find any unintentional breaks. But every time we fix a bug there’s the risk that some application depended on that wrong behavior. Sometimes applications take dependencies we have warned against, such as the behavior of private APIs or the description text of exceptions. Since the .NET Framework was introduced, we’ve had a good solution for application compatibility: allow multiple versions of the .NET Framework to be installed on the same machine at the same time. This enables two different applications, built against two different versions and installed on one machine, to each run against the appropriate version. What Does In-Process Side-by-Side Mean to You?End Users and System Administrators: You now can have confidence that when you install a new version of the runtime, either independently or with an application, it will have no impact on your machine, and all existing applications will continue to run as they did before. Application Developers: In-Proc SxS has almost no impact on application developers. Applications have always defaulted to run against the version of the framework on which they were built and this has not changed. The only change in behavior we have made that impacts application developers is that we will no longer automatically run an application built against an older runtime on a newer version when the original version is not present. Instead we will prompt the user to download the original version and provide a link to make it easy to do so. We still provide configuration options that allow you to indicate which versions of the framework you want your application to run against, so it is possible to run an older application on a newer runtime, but we won’t do it automatically. Library Developers and Consumers: In-Proc SxS does not solve the compatibility problems faced by library developers. Any libraries directly loaded by an application—either via a direct reference or an Assembly.Load*—will continue to load directly into the runtime and AppDomain of the application loading it. This means that if an application is recompiled to run against the .NET Framework 4 runtime and still has dependent assemblies built against .NET 2.0, those dependents will load on the .NET 4 runtime as well. Therefore, we still recommend testing your libraries
against all version of the framework you wish to support. This is one of the reasons we have continued to maintain our high level of backward compatibility. Managed COM Component Developers: Read more: MSDN magazine