Export (0) Print
Expand All

Side-by-Side Execution and ADO.NET 

Side-by-side execution in the .NET Framework is the ability to execute an application, on a computer with multiple versions of the .NET Framework installed, exclusively using the version that the application was compiled for. For detailed information on configuring side-by-side execution, see Side-by-Side Execution.

An application compiled using one version of the .NET Framework can run on a different version of the .NET Framework. However, we recommend that you compile a version of the application for each installed version of the .NET Framework, and run them separately. In either scenario, you should be aware of changes in ADO.NET between releases that can affect the forward compatibility or backward compatibility of your application.

Forward Compatibility and Backward Compatibility

Forward compatibility means that an application can be compiled with an earlier version of the .NET Framework, but will still run successfully on a later version of the .NET Framework. ADO.NET code written for the .NET Framework version 1.1 is forward compatible with the .NET Framework version 2.0.

Backward compatibility means that an application is compiled for a newer version of the .NET Framework, but continues to run on earlier versions of the .NET Framework without any loss of functionality. Of course, this will not be the case for features introduced in a new version of the .NET Framework. For information about the new features added to ADO.NET in the 2.0 version of the.NET Framework, see What's New in ADO.NET.

Although the ADO.NET Components in the .NET Framework are designed to be both forward and backward compatible (excluding new features), you should be aware of several issues that affect the forward or backward compatibility of an application.

The following sections describe side-by-side execution issues that can affect the backward or forward compatibility of your ADO.NET code including:

  • The .NET Framework Data Provider for ODBC

  • The .NET Framework Data Provider for Oracle

  • Code Access Security

  • The DataSet

  • SqlCommand execution

  • Microsoft Data Access Components (MDAC)

The .NET Framework Data Provider for ODBC

Starting with version 1.1, the .NET Framework Data Provider for ODBC (System.Data.Odbc) is included as a part of the .NET Framework. The ODBC data provider is available to .NET Framework version 1.0 developers as a Web download from the Data Access and Storage Developer Center. The namespace for the downloaded .NET Framework Data Provider for ODBC is Microsoft.Data.Odbc.

If you have an application developed for the .NET Framework version 1.0 that uses the ODBC data provider to connect to your data source, and you want to run that application on the .NET Framework version 1.1 or later, you must update the namespace for the ODBC data provider to System.Data.Odbc. You then must recompile it for the newer version of the .NET Framework.

If you have an application developed for the .NET Framework version 2.0 that uses the ODBC data provider to connect to your data source, and you want to run that application on the .NET Framework version 1.0, you must download the ODBC data provider and install it on the .NET Framework version 1.0 system. You then must change the namespace for the ODBC data provider to Microsoft.Data.Odbc, and recompile the application for the .NET Framework version 1.0.

The .NET Framework Data Provider for Oracle

Starting with version 1.1, the .NET Framework Data Provider for Oracle (System.Data.OracleClient) is included as a part of the .NET Framework. The data provider is available to .NET Framework version 1.0 developers as a Web download from the Data Access and Storage Developer Center.

If you have an application developed for the .NET Framework version 2.0 that uses the data provider to connect to your data source, and you want to run that application on the .NET Framework version 1.0, you must download the data provider and install it on the .NET Framework version 1.0 system.

Code Access Security

The .NET Framework data providers in the .NET Framework version 1.0 (System.Data.SqlClient, System.Data.OleDb) are required to run with FullTrust permission. Any attempt to use the .NET Framework data providers from the .NET Framework version 1.0 in a zone with less than FullTrust permission causes a SecurityException.

However, with the release of the.NET Framework version 2.0, all of the .NET Framework data providers can be used in partially trusted zones. In addition, a new security feature was added to the .NET Framework data providers in the .NET Framework version 1.1. This feature enables you to restrict what connection strings can be used in a particular security zone. You can also disable the use of blank passwords for a particular security zone. For more information, see Code Access Security and ADO.NET.

Because each installation of the .NET Framework has a separate Security.config file, there are no compatibility issues with security settings. However, if your application depends on the additional security capabilities of ADO.NET included in the .NET Framework version 1.1 and later, you will not be able to distribute it to a version 1.0 system.

SqlCommand Execution

Starting with the .NET Framework version 1.1, the way that ExecuteReader executes commands at the data source was changed.

In the .NET Framework version 1.0, ExecuteReader executed all commands in the context of the sp_executesql stored procedure. As a result, commands that affect the state of the connection (for example, SET NOCOUNT ON), only apply to the execution of the current command. The state of the connection is not modified for any subsequent commands executed while the connection is open.

In the .NET Framework version 1.1 and later, ExecuteReader only executes a command in the context of the sp_executesql stored procedure if the command contains parameters, which provides a performance benefit. As a result, if a command affecting the state of the connection is included in a non-parameterized command, it modifies the state of the connection for all subsequent commands executed while the connection is open.

Consider the following batch of commands executed in a call to ExecuteReader.

SET NOCOUNT ON;
SELECT * FROM dbo.Customers;

In the .NET Framework version 1.1 and later, NOCOUNT will remain ON for any subsequent commands executed while the connection is open. In the .NET Framework version 1.0, NOCOUNT is only ON for the current command execution.

This change can affect both the forward and backward compatibility of your application if you depend on the behavior of ExecuteReader for either version of the .NET Framework.

For applications that run on both earlier and later versions of the .NET Framework, you can write your code to ensure that the behavior is the same regardless of the version you are running on. If you want to ensure that a command modifies the state of the connection for all subsequent commands, we recommend that you execute your command using ExecuteNonQuery. If you want to ensure that a command does not modify the connection for all subsequent commands, we recommend that you include the commands to reset the state of the connection in your command. For example:

SET NOCOUNT ON;
SELECT * FROM dbo.Customers;
SET NOCOUNT OFF;

Microsoft Data Access Components (MDAC)

The .NET Framework data providers for OLE DB and ODBC require MDAC 2.6 or later in all versions of the .NET Framework, and MDAC 2.8 SP1 is recommended. Although this requirement introduces no side-by-side execution issues, it is important to note that MDAC does not currently support side-by-side execution. Therefore, it is important to verify that your application will continue to function properly with the new version before upgrading the MDAC components for your installation.

For more information about MDAC, see the Data Access and Storage Developer Center.

See Also

Community Additions

ADD
Show:
© 2014 Microsoft