.NET Framework Assembly Unification
In side-by-side execution, it is possible for an application to be composed of components that are built using different versions of the .NET Framework. This can create conflicts between the dependencies of the components. For example, suppose component A is built using .NET Framework version 1.1 and needs to use version 1.1 of the System.Data assembly. Component B is built using the .NET Framework version 1.1 and needs to use version 2.0 of the System.Data assembly. If the assembly versions are incompatible, but are loaded at the same time, this could lead to unintended type mismatches or other problems.
How an Application Determines Which .NET Framework Version to Use
To allow different versions of the same assembly to be used, when an application uses components that are built on different versions of the .NET Framework, the version that is associated with an application determines which version of the .NET Framework assemblies are used by the application and by all of its components. In the example, if the application is mapped to version 2.0 of the .NET Framework, version 2.0 of the System.Data assembly is loaded and shared by all components used in the application. The reference from component A to version 1.1 of the System.Data assembly is promoted at run time to reference version 2.0.
If you obtain an updated version of a specific assembly, you can associate your application with the assembly independently of the version of the .NET Framework your application is mapped to. To do so, you can add <bindingRedirect> elements to the Machine.config or Web.config files. These elements associate an application with an updated assembly that replaces an existing assembly for certain types of applications. For example, if an updated version of System.Web.Service.dll is released in the future that supports SOAP version 1.2, you might want your application to use that version instead of the version that was installed with the .NET Framework originally.
This behavior can also be overridden in the ASP.NET host configuration file (Aspnet.config). ASP.NET uses this file to ensure that the versions of System.Web.dll and System.Web.RegularExpressions.dll always match the version associated with an application, regardless of any overrides specified in the Web.config file.
Sometimes you might want to use a component that was built using a later version of ASP.NET in an application built with an earlier version. The ASPNET ISAPI version associated with an application always determines the version of the runtime used for an application. If the application is configured to use the earlier version of the .NET Framework, the component will automatically be redirected at run time to use that version as well.
When using a component built with a later version of the .NET Framework in an application built on an earlier version, consider the following:
Make sure the component does not use any features or depend on any behaviors specific to the later version of the .NET Framework. These features might not be available in the earlier version of the runtime.
ASP.NET uses script maps in IIS to bind an application to a version of the runtime. <supportedRuntime> and <requiredRuntime> configuration elements are not applicable to ASP.NET applications.
Alternatively, if the runtime version used to build the component is installed on the computer, you could also reconfigure the application to use the later runtime version. Since later versions of the .NET Framework are designed in general to be backward compatible, most application features should work without many modifications. However, you should test carefully to be sure that running the application under a new version of the .NET Framework does not introduce errors into your application.
For information on configuring an ASP.NET application to use a specific version of the runtime, see How to: Configure ASP.NET Applications for an ASP.NET Version.