Condividi tramite

Controllo dell'installazione del provider di dati .NET

Quando si usano provider .NET in Microsoft .NET, è fondamentale comprendere i vari componenti e le relative dipendenze per una perfetta integrazione nelle applicazioni. Questo articolo illustra gli aspetti essenziali dei provider .NET, i percorsi di ricerca predefiniti e le linee guida per la risoluzione dei problemi.

Note

Questo articolo non tratta le installazioni di .NET Core.

Provider di dati Microsoft .NET

Microsoft .NET include quattro provider di dati forniti con .NET Framework:

  • System.Data.SqlClient
  • System.Data.Odbc
  • System.Data.OleDb
  • System.Data.OracleClient

I primi tre sono contenuti in System.Data.DLL e l'ultimo è contenuto in System.Data.OracleClient.DLL. Quando si compila un'applicazione, è sufficiente aggiungere un riferimento alla DLL appropriata (nota anche come "assembly") al progetto e quindi è possibile usare il provider.

System.Data.SqlClient contiene codice di implementazione simile a SQL Native Client e non si basa affatto sulle API OLE DB o ODBC .

System.Data.Odbc e System.Data.OleDb non forniscono alcuna funzionalità intrinseca del database. Caricano invece rispettivamente i driver ODBC e i provider OLE DB.

System.Data.OracleClient contiene anche codice di implementazione, ma come i driver ODBC Oracle e i provider OLE DB, si basa anche sul software Client Oracle o sul software Oracle Data Access Components (ODAC) da installare.

Note

In generale, è consigliabile usare driver forniti da Oracle anziché implementazioni di Microsoft, perché è probabile che i driver precedenti siano più aggiornati. Se un problema può essere risolto passando a un provider Oracle da un'implementazione del driver Microsoft, si tratta di una soluzione preferita.

Percorso di ricerca .NET predefinito

A differenza del caricamento di driver ODBC e provider OLE DB, i provider di dati .NET non si basano sul Registro di sistema. Il caricatore .NET usa invece un'euristica di ricerca descritta di seguito:

  1. La DEVPATH variabile di ambiente viene controllata per una cartella condivisa. È consigliabile usarlo solo quando si sviluppano assembly condivisi. Al termine dello sviluppo, l'assembly deve essere installato nella Global Assembly Cache (GAC).
  2. La GAC viene controllata per verificare se l'assembly è condiviso tra le applicazioni. Se l'assembly non è presente nella GAC, si tratta di un assembly privato.
  3. Se l'applicazione o il file di configurazione Web ha un elemento, l'attributo href assegna il nome e il percorso assoluto del file contenente il manifesto dell'assembly.
  4. Viene selezionata la cartella in cui è installata l'applicazione.
  5. Viene verificata una sottocartella nella cartella dell'applicazione con lo stesso nome del file contenente il manifesto dell'assembly.
  6. Se il file di configurazione contiene un elemento, l'attributo privatePath assegna il nome di una o più sottocartelle da cercare nella cartella dell'applicazione.

L'euristica della ricerca è un algoritmo di caricamento DLL generale. Usando i provider .NET predefiniti, la DLL è quasi sempre in una delle cartelle seguenti:

  • C:\windows\microsoft.net\Framework (assembly a 32 bit)
  • C:\windows\microsoft.net\Framework64 (assembly a 64 bit)

In queste cartelle sarà presente una cartella per le varie versioni di .NET. In genere, siamo interessati solo a:

  • v2.0.50727 (.NET 2.0, 3.0, 3.5)
  • v4.0.30319 (.NET 4.x)

È possibile notare le cartelle .NET 1.0 e 1.1. Questi elementi non sono supportati e non contengono assembly. È anche possibile notare le cartelle .NET 3.0 e 3.5. Anche se questi possono contenere determinati file specifici di queste versioni di .NET, sono tutte estensioni alla versione 2.0 e System.Data.DLL si trova nella cartella 2.0 perché non è una DLL di estensione. Le cartelle indicate in precedenza sono le posizioni delle DLL framework predefinite.

Inoltre, queste DLL e DLL di terze parti vengono visualizzate nella GAC, dove l'algoritmo di ricerca sembra. La GAC si trova in:

  • C:\windows\assembly (per .NET Framework 2.0, 3.0, 3.1, 4.x).

Alcuni assembly .NET 4.0 si trovano anche in:

  • C:\windows\microsoft.net\assembly.

Per linee guida più complete, vedere How the Runtime Locates Assemblies .For more complete guidelines, see How the Runtime Locates Assemblies. L'uso di PROCMON può anche rivelare il percorso di ricerca.

Provider di terzi

Molti provider installati da Microsoft come Analysis Services non sono dotati di .NET Framework. Sono inoltre presenti provider .NET di terze parti, ad esempio il provider ODP di Oracle, installati in modo indipendente.

Per i provider di terze parti, assicurarsi che l'assembly si trovi in una delle cartelle seguenti e che sia a 64 bit o a 32 bit a seconda dell'applicazione:

  • C:\windows\microsoft.net\assembly (per le versioni di .NET Framework 4.x)
  • C:\windows\assembly (per .NET Framework 2.0, 3.0, 3.1, 4.x)

La tabella seguente illustra i nomi di DLL e assembly di alcuni provider comuni:

Nome descrittivo Nome assembly DLL
Provider di dati .NET per SQL Server System.Data.SqlClient System.Data.DLL
Provider OLE DB System.Data.OleDb System.Data.DLL
ODBC Provider System.Data.Odbc System.Data.DLL
Analysis Services Provider Analysis Services Provider Microsoft.AnalysisServices.AdomdClientMicrosoft.AnalysisServices.AdomdClient.DLL
SQL CE Provider System.Data.SqlServerCe System.Data.SqlServerCe.DLL
Provider Oracle di Microsoft System.Data.OracleClient System.Data.OracleClient.DLL
Provider ODP di Oracle Oracle.DataAccess.Client Oracle.DataAccess.DLL

Durante la risoluzione dei problemi relativi ai provider .NET, non esiste uno strumento predefinito o generalizzato, ad esempio l'amministratore ODBC o un file UDL, per testare l'applicazione in modo indipendente. In questi casi, è possibile scrivere un'applicazione di test rapido in una lingua di propria scelta. Ecco un'applicazione di esempio scritta in PowerShell:

#-------------------------------
#
# get-SqlAuthScheme.ps1
#
# PowerShell script to test a System.Data.SqlClient database connection
#
# USAGE: .\get-SqlAuthScheme tcp:SQLProd01.contoso.com,1433   ' explicitly specify DNS suffix, protocol, and port # ('tcp' must be lower case)
# USAGE: .\get-SqlAuthScheme SQLProd01                        ' let the driver figure out the DNS suffix, protocol, and port #
#
#-------------------------------
param ([string]$server = "localhost")
Set-ExecutionPolicy Unrestricted -Scope CurrentUser
$connstr = "Server=$server;Database=master;Integrated Security=SSPI"

[System.Data.SqlClient.SqlConnection] $conn = New-Object System.Data.SqlClient.SqlConnection
$conn.ConnectionString = $connstr

[System.DateTime] $start = Get-Date

$conn.Open()

[System.Data.SqlClient.SqlCommand] $cmd = New-Object System.Data.SqlClient.SqlCommand
$cmd.CommandText = "select auth_scheme from sys.dm_exec_connections where session_id=@@spid"
$cmd.Connection = $conn
$dr = $cmd.ExecuteReader()
$result = $dr.Read()
$auth_scheme = $dr.GetString(0)

$conn.Close()
$conn.Dispose()

[System.DateTime] $end = Get-Date
[System.Timespan] $span = ($end - $start)

"End time: " + $end.ToString("M/d/yyyy HH:mm:ss.fff")
"Elapsed time was " + $span.Milliseconds + " ms."
"Auth scheme for " + $server + ": " + $auth_scheme

Se lo script si trova in C:\temp e si vuole recuperare lo schema di autenticazione per un server denominato sqlprod01, eseguire il comando seguente da Windows PowerShell come amministratore:

.\get-sqlauthscheme.ps1 sqlprod01

In generale, il caricamento dei provider .NET non sarà un problema se l'assembly/DLL esiste. Il problema più comune è rappresentato dai problemi di autenticazione, che è possibile testare usando un provider OLE DB equivalente tramite un file UDL.

Per informazioni sui stringa di connessione per i driver non familiari, vedere Informazioni di riferimento sulle stringhe di connessione.

Ulteriori informazioni

  • Last updated on