Assembly Unification in the .NET Framework
Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1
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 the .NET Framework version 1.0 and needs to use version 1.0 of the System.Data assembly. Component B is built using the .NET Framework version 1.1 and needs to use version 1.1 of the System.Data assembly. If the assembly versions are incompatible, but are loaded at the same time, this could lead to unintended type casting exceptions, or even worse problems.
How an Application Determines Which .NET Framework Version to Use
To solve this problem, when an application uses components that are built on different versions of the .NET Framework, the runtime version that is associated with an application determines which version of the .NET Framework assemblies are used by the application and all its components. In the previous example, if the application is associated with version 1.1 of the .NET Framework, version 1.1 of the System.Data assembly is then loaded and shared across all components used by the application. The reference from component A to version 1.0 of the System.Data assembly is promoted at run time to reference version 1.1.
You can override this behavior by adding <bindingRedirect> elements to the Machine.config or Web.config files. This allows an application to use an updated assembly version that was designed to replace 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 runtime originally.
Note
For more information, see the <bindingRedirect> topic in .NET Framework Help.
This behavior can also be overridden in the ASP.NET host configuration file (Aspnet.config). ASP.NET uses this file to ensure that the version of System.Web.dll and System.Web.RegularExpressions.dll always matches the runtime version associated with an application, regardless of any overrides 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. Remember that 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 runtime, the component will be automatically redirected at runtime 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 to be backward compatible, the application should work without any modifications. For information about configuring an ASP.NET application to use a specific version of the runtime, see Configuring an ASP.NET Application for an ASP.NET Version.