Versioning, Compatibility, and Side-by-Side Execution in the .NET Framework

Introduction

As the launch of Microsoft Windows® Server 2003 and Visual Studio .NET 2003 approaches, it is time to detail some of the behavioral changes between versions 1.0 and 1.1 of the .NET Framework, including how these changes might affect customers and what customers can do about them.

The .NET Framework team is committed to compatibility from version to version. The majority of applications built against the .NET Framework version 1.0 should execute flawlessly on version 1.1 and future releases. Nevertheless, rare but inevitable situations will arise in which we will have to make changes to the common language runtime (CLR) or class libraries—for example, to correct security or other behavioral issues—that can affect some applications.

Historically, many platform vendors forced users to upgrade to the latest version shipped. Software developers programming for that platform were responsible for resolving any resulting incompatibilities. In contrast, the .NET Framework team is putting complete control in the hands of the systems administrators and the developers who use the Framework through a technology called side-by-side execution.

In many ways, the side-by-side model introduced in the .NET Framework version 1.1 is the same model that Microsoft Visual Basic® has used for years. Each version of Visual Basic released a new version of the Visual Basic runtime (vbrun.dll). All code built with Visual Basic 5.0 required vbrun.dll version 5.0 to be installed on the system. When Visual Basic 6.0 was introduced, a new runtime was introduced to accompany it. The vbrun.dll for Visual Basic 6.0 could exist on the same system as version 5.0. Both could run simultaneously, each hosting the applications built against that particular version.

The main difference between the old Visual Basic model and the side-by-side execution approach for the .NET Framework is that with the old Visual Basic model an application could be upgraded to run with the new runtime only if a developer recompiled the application using the newer toolset. In the case of side-by-side execution, systems administrators—after testing that a given application is compatible with the new version of the .NET Framework—now have the power to upgrade an application simply by modifying the application's configuration file. For specific guidance and examples, read Side-by-Side Execution of the .NET Framework in the MSDN® Library. (Naturally, the developer can still exert control by shipping a version of the application recompiled against the new version of the .NET Framework).

At a high level, then, side-by-side execution enables multiple versions of the .NET Framework to be present on a system and execute concurrently without interfering with each other.

To ensure a complete understanding of this technology, read the following detailed discussion of the default behavior.

Top of Page

Upgrade Behavior for Windows Services, Windows Forms, and Console Applications

By default, upgrade behavior for Windows Services, Windows Forms, and console applications installed locally is as follows:

• A version 1.0 application installed on a system with only version 1.1 of the .NET Framework present will try to run against version 1.1 unless the administrator explicitly disallows this behavior.
• A version 1.0 application installed on a system with both 1.1 and 1.0 of the Framework will run against 1.0 unless an administrator changes this behavior.
• A version 1.1 application installed on a system with both 1.1 and 1.0 of the Framework will run against 1.1 unless an administrator changes this behavior.*
• A version 1.1 application installed on a system with only 1.0 will not run unless an administrator changes this behavior.*

Again, administrators may override the default behavior by simply adding XML tags to the relevant application's configuration file, creating that file if it does not already exist. Specific guidance on and examples of this behavior, along with behavior and scenarios for ASP.NET applications, COM interop, and Microsoft Internet Explorer hosting scenarios (such as no-touch deployment and Windows Forms controls embedded in a Web page), COM+ scenarios, and dynamic-link libraries (DLLs), may be found in the product documentation and in Side-by-Side Execution of the .NET Framework in the MSDN Library.

Top of Page

Visual Studio .NET and Versioning

Many developers will wonder how Visual Studio is affected by side-by-side execution.

Visual Studio .NET 2003 is capable of producing code that executes on the .NET Framework version 1.1 while Visual Studio .NET 2002 is capable of producing code that executes on the .NET Framework version 1.0. Consistent with the behavior followed by previous releases of Microsoft developer tools, each version of Visual Studio targets only the version of the .NET Framework with which it shipped.

Neither tool provides the ability to target other versions. When a project created with Visual Studio .NET 2002 is opened in Visual Studio .NET 2003, the tool will offer to upgrade the project automatically to the .NET Framework version 1.1. If accepted, this procedure is irreversible, as the project may then be changed by the developer in a way that depends on functionality made available only in version 1.1. If the upgrade is refused, Visual Studio .NET 2003 will not open the project.

Applications built with the .NET Framework using Visual Studio .NET 2002 and Visual Studio .NET 2003 will benefit from side-by-side execution. Both versions of Visual Studio .NET can be installed and execute on the same machine simultaneously for those developers who choose to support solutions on both versions of the .NET Framework.

*Note: A .NET Framework version 1.1 application should not be redirected to run on the .NET Framework version 1.0 unless it was built with version 1.0 in mind, such that it does not take advantage of any functionality or behavior present in 1.1 but not in 1.0. For more information, see Side-by-Side Execution of the .NET Framework.