Esecuzione contemporanea di diverse versioni e ADO.NET

Articolo
04/11/2008

In .NET Framework il supporto dell'esecuzione contemporanea di diverse versioni indica la possibilità di eseguire un'applicazione su un computer su cui sono installate più versioni di .NET Framework, senza conseguenze per l'applicazione. Anche se sul computer vi sono più versioni di .NET Framework, l'applicazione utilizza la versione per la quale è stata compilata e non viene influenzata dalla presenza delle altre versioni. Per informazioni dettagliate sulla configurazione dell'esecuzione contemporanea di diverse versioni, vedere Esecuzione contemporanea di diverse versioni.

Non è escluso che un'applicazione compilata utilizzando una versione di .NET Framework possa essere eseguita su una diversa versione di .NET Framework. Si consiglia tuttavia di compilare versioni dell'applicazione diverse per ciascuna versione di .NET Framework installata e di eseguirle separatamente. In ogni scenario è opportuno tenersi informati sulle modifiche apportate ad ADO.NET tra una versione e l'altra per valutarne il possibile impatto sulla compatibilità della propria applicazione con le versioni successive o precedenti.

Compatibilità con le versioni successive e precedenti

Per compatibilità con le versioni successive si intende la possibilità di compilare ed eseguire un'applicazione con versioni sia successive che precedenti di .NET Framework. Il codice ADO.NET, scritto per .NET Framework versione 1.1, è compatibile con le versioni successive purché non si utilizzino le nuove funzionalità introdotte con .NET Framework versione 1.1. Le nuove funzionalità aggiunte ad ADO.NET in .NET Framework versione 1.1 sono:

Il metodo EnlistDistributedTransaction di Connection. Vedere Inserimento in una transazione distribuita.
La proprietà HasRows di DataReader. Vedere Recupero di dati mediante DataReader.
L'aggiunta del provider di dati .NET Framework per ODBC. Vedere Spazio dei nomi System.Data.Odbc.
L'aggiunta del provider di dati .NET Framework per Oracle. Vedere Spazio dei nomi System.Data.OracleClient.

Compatibilità con le versioni precedenti significa che un'applicazione è compilata per una versione precedente di .NET Framework, ma può essere eseguita su versioni successive di .NET Framework senza che l'efficienza ne sia compromessa.

Benché i componenti di ADO.NET forniti con .NET Framework versione 1.1 siano progettati per offrire compatibilità con le versioni sia successive che precedenti (fatta eccezione per le nuove funzionalità), ai fini della compatibilità delle applicazioni occorre tenere conto di diversi fattori.

Gli elementi dell'esecuzione contemporanea di diverse versioni che possono incidere sulla compatibilità del codice ADO.NET con le versioni successive e precedenti sono indicati di seguito. I temi trattati in questo argomento sono:

Provider di dati .NET Framework per ODBC
Provider di dati .NET Framework per Oracle
Protezione dall'accesso di codice
DataSet
Esecuzione di SqlCommand
Versione di MDAC

Provider di dati .NET Framework per ODBC

Il provider di dati .NET Framework per ODBC (System.Data.Odbc) viene fornito con .NET Framework a partire dalla versione 1.1. Il provider di dati per ODBC non viene fornito con .NET Framework versione 1.0. Gli sviluppatori che utilizzano .NET Framework versione 1.0 possono effettuare il download del provider di dati per ODBC all'indirizzo https://msdn.microsoft.com/downloads/ (informazioni in lingua inglese). Lo spazio dei nomi del provider di dati .NET Framework per ODBC è Microsoft.Data.Odbc.

Se si dispone di un'applicazione sviluppata per .NET Framework versione 1.0 che effettua la connessione a un'origine dati utilizzando il provider di dati ODBC e si desidera eseguire tale applicazione su .NET Framework versione 1.1, sarà necessario aggiornare lo spazio dei nomi per il provider di dati ODBC in System.Data.Odbc. Ricompilare quindi l'applicazione per .NET Framework versione 1.1.

Se si dispone di un'applicazione sviluppata per .NET Framework versione 1.1 che effettua la connessione a un'origine dati utilizzando il provider di dati ODBC e si desidera eseguire tale applicazione su .NET Framework versione 1.0, sarà necessario effettuare il download del provider di dati ODBC e installarlo sul computer che esegue .NET Framework versione 1.0. Prima di ricompilare l'applicazione per .NET Framework versione 1.0, occorrerà inoltre modificare lo spazio dei nomi del provider di dati ODBC in Microsoft.Data.Odbc.

Provider di dati .NET Framework per Oracle

Il provider di dati .NET Framework per Oracle (System.Data.OracleClient) viene fornito con .NET Framework a partire dalla versione 1.1. Il provider di dati non viene fornito con .NET Framework versione 1.0. Gli sviluppatori che utilizzano .NET Framework versione 1.0 possono effettuare il download del provider di dati all'indirizzo https://msdn.microsoft.com/downloads/ (informazioni in lingua inglese).

Se si dispone di un'applicazione sviluppata per .NET Framework versione 1.1 che effettua la connessione a un'origine dati utilizzando il provider di dati e si desidera eseguire tale applicazione su .NET Framework versione 1.0, sarà necessario effettuare il download del provider di dati e installarlo sul computer che esegue .NET Framework versione 1.0.

Protezione dall'accesso di codice

I provider di dati .NET Framework utilizzati con .NET Framework versione 1.0 (System.Data.SqlClient e System.Data.OleDb) devono essere eseguiti con autorizzazioni FullTrust. Ogni tentativo di utilizzare i provider di dati .NET Framework con .NET Framework versione 1.0 in una zona con autorizzazioni inferiori a FullTrust causa una SecurityException.

Con .NET Framework versione 1.1, il provider di dati .NET Framework per SQL Server può essere invece utilizzato anche in zone ad attendibilità parziale. Per i provider di dati per OLE DB e ODBC sono ancora necessarie autorizzazioni FullTrust.

Con .NET Framework versione 1.1 è stata aggiunta ai provider di dati .NET Framework una nuova funzionalità di protezione, che permette di definire quali stringhe di connessione possano essere utilizzate in una determinata zona di protezione. È anche possibile disattivare l'utilizzo di password vuote per una particolare zona di protezione. Per ulteriori informazioni, vedere Protezione dall'accesso di codice e ADO.NET.

Poiché ogni installazione di .NET Framework dispone di un file Security.config separato (vedere File di configurazione della protezione), le impostazioni di protezione non sollevano problemi di compatibilità con versioni successive o precedenti. Se però un'applicazione dipende dalle funzionalità di protezione aggiuntive di ADO.NET incluse in .NET Framework versione 1.1, non sarà possibile eseguirla su un computer che utilizza la versione 1.0.

DataSet

Al DataSet fornito con .NET Framework versione 1.1 sono state apportate diverse correzioni che ne modificano il funzionamento rispetto al DataSet fornito con .NET Framework versione 1.0. Il codice basato sul funzionamento della versione 1.0 potrebbe presentare problemi di compatibilità con le versioni precedenti. Le modifiche apportate al funzionamento del DataSet sono indicate di seguito.

I valori di colonna predefiniti che vengono impostati come stringhe vuote nello schema XSD (XML Schema Definition Language) di un DataSet non vengono più interpretati come null.
I vincoli vengono convalidati dopo la modifica della proprietà Locale.
Se lo schema del proprio DataSet contiene elementi con lo stesso nome, ma di tipo diverso, nello stesso spazio dei nomi, con la versione 1.1 viene generata un'eccezione quando si tenta di leggere lo schema in un DataSet o quando il DataSet è utilizzato in modalità remota da un client versione 1.1. Nel caso, ad esempio, di due tabelle correlate, dove una colonna della tabella padre ha lo stesso nome della tabella figlio, si verificherà un'eccezione se la proprietà Nested di DataRelation è true. In questo caso, infatti, la tabella figlio si troverebbe nello stesso spazio dei nomi della tabella padre nello schema XML del DataSet. Se la proprietà Nested di DataRelation è false, l'eccezione non verrà generata.
L'impostazione della proprietà AllowDBNull di una colonna su false e della proprietà ColumnMapping della colonna su MappingType.Attribute rappresenta un caso particolare quando si pone un DataSet tra i servizi remoti. Per un DataSet posto tra i servizi remoti da un sistema versione 1.0, si verifica un'eccezione quando il client tenta di caricare il DataSet remoto. Per un DataSet posto tra i servizi remoti da un sistema versione 1.1, non si verifica alcuna eccezione. I sistemi versione 1.0 non possono leggere il DefaultValue della colonna. Per i sistemi 1.0, il DefaultValue della colonna è String.Empty.
Se lo schema XML di un DataSet include un targetNamespace, è possibile che non si riesca a leggere i dati e che si verifichino eccezioni quando si chiama ReadXml per caricare il DataSet con un XML che contiene elementi privi di uno spazio dei nomi qualificativo. In questo caso, per leggere elementi non qualificati, impostare elementFormDefault uguale a "qualified" nello schema XML. Esempio:
```
<xsd:schema id="MyDataSet" 
  elementFormDefault="qualified"
  targetNamespace="http://www.tempuri.org/MyDataSet.xsd" 
  xmlns="http://www.tempuri.org/MyDataSet.xsd" 
  xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
  xmlns:msdata="urn:schemas-microsoft-com:xml-msdata">
</xsd:schema>
```

Esecuzione di SqlCommand

Con .NET Framework versione 1.1 è cambiato il modo in cui SqlCommand.ExecuteReader esegue comandi sull'origine dati.

In .NET Framework versione 1.0, SqlCommand.ExecuteReader esegue tutti i comandi nel contesto della stored procedure sp_executesql. Di conseguenza, tutti i comandi che agiscono sullo stato della connessione (ad esempio SET NOCOUNT ON) riguardano solo l'esecuzione del comando corrente. Lo stato della connessione non viene modificato per i comandi successivi eseguiti fintanto che la connessione è aperta.

In .NET Framework versione 1.1, SqlCommand.ExecuteReader esegue un comando nel contesto della stored procedure sp_executesql solo se il comando contiene parametri, poiché ciò comporta vantaggi per le prestazioni. Di conseguenza, se i comandi che incidono sullo stato della connessione vengono inclusi in un comando senza parametri, le modifiche apportate allo stato della connessione permarranno anche per tutti i comandi eseguiti successivamente, fino alla chiusura della connessione.

Si consideri l'esecuzione del gruppo di comandi riportato di seguito in una chiamata a SqlCommand.ExecuteReader.

SET NOCOUNT ON;
SELECT * FROM Customers;

In .NET Framework versione 1.1, NOCOUNT resta ON per tutti i comandi eseguiti fintanto che la connessione è aperta. In .NET Framework versione 1.0, NOCOUNT resta ON solo durante l'esecuzione del comando corrente.

Tale modifica può incidere sulla compatibilità di un'applicazione con le versioni successive e precedenti, se l'applicazione dipende dal funzionamento di SqlCommand.ExecuteReader di una delle versioni di .NET Framework.

Se si richiede che le applicazioni possano essere eseguite sia sulle versioni successive che sulle versioni precedenti di .NET Framework, è possibile scrivere codice tale che il funzionamento resti invariato indipendentemente dalla versione su cui l'applicazione viene eseguita. Per essere certi che un comando modifichi lo stato della connessione per tutti i comandi successivi, si consiglia di eseguire il comando tramite SqlCommand.ExecuteNonQuery. Per essere certi che un comando non modifichi lo stato della connessione per tutti i comandi successivi, si consiglia di includervi il comando che ripristina lo stato della connessione. Esempio:

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

Versione di MDAC

Per utilizzare i provider di dati .NET Framework di qualsiasi versione di .NET Framework, è necessario installare MDAC 2.6 o versione successiva. Benché non la comprometta, è importante osservare che correntemente MDAC non supporta l'esecuzione contemporanea di diverse versioni. Prima di aggiornare i componenti MDAC per la propria installazione, è bene verificare che la propria applicazione continui a funzionare correttamente con la nuova versione.

Vedere anche

Cenni preliminari su ADO.NET | Architettura di ADO.NET | Utilizzo di provider di dati .NET Framework per accedere ai dati