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。 

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 make sure that the behavior is the same regardless of the version you are running on。 If you want to make sure 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 make sure 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: 

Microsoft SQL Server Native Client 

Microsoft SQL Server Native Client contains the SQL OLE DB provider and SQL ODBC driver in one native dynamic link library (DLL) supporting applications using native-code APIs (ODBC, OLE DB and ADO) to Microsoft SQL Server。 SQL Server Native Client should be used rather than Microsoft Data Access Components (MDAC) to create new applications or enhance existing applications that need to take advantage of features that were introduced in SQL Server 2005, such as Multiple Active Result Sets (MARS), Query Notifications, User-Defined Types (UDT), and XML data type support。 

Microsoft Data Access Components (MDAC) 

The 。NET Framework data providers for OLE DB and ODBC require MDAC 2。6 or a later version in all versions of the 。NET Framework, and MDAC 2。8 SP1 is recommended。 Although this requirement introduces no side-by-side execution issues, notice that MDAC does not currently support side-by-side execution。 Therefore, it is important to verify that your application will continue to function correctly 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。 

Windows Data Access Components (Windows DAC) 

Windows Data Access Components (Windows DAC) 6。0 is a set of technologies included in Windows Vista to provide access to information across the enterprise。 These technologies include the latest versions of the data access technologies included in MDAC: Microsoft ActiveX Data Objects (ADO), OLE DB, and Microsoft Open Database Connectivity (ODBC)。