Compartir a través de


Comprobación de instalación del proveedor de datos de .NET

Al usar proveedores de .NET en Microsoft .NET, es fundamental comprender los distintos componentes y sus dependencias para la integración sin problemas en las aplicaciones. En este artículo se describen los aspectos esenciales de los proveedores de .NET, sus rutas de búsqueda predeterminadas y las directrices de solución de problemas.

Nota:

En este artículo no se tratan las instalaciones de .NET Core.

Proveedores de datos de Microsoft .NET

Microsoft .NET incluye cuatro proveedores de datos que se incluyen con .NET Framework:

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

Las tres primeras están contenidas en System.Data.DLL y la última está contenida en System.Data.OracleClient.DLL. Al compilar una aplicación, solo tiene que agregar una referencia al archivo DLL adecuado (también conocido como "ensamblado") al proyecto y, a continuación, puede usar el proveedor.

System.Data.SqlClient contiene código de implementación similar a SQL Native Client y no se basa en las API OLE DB o ODBC en absoluto.

System.Data.Odbc y System.Data.OleDb no proporcionan ninguna funcionalidad inherente de la base de datos. En su lugar, cargan controladores ODBC y proveedores OLE DB, respectivamente.

System.Data.OracleClient también contiene código de implementación, pero, al igual que los controladores ODBC de Oracle y los proveedores OLE DB, también se basa en el software cliente de Oracle o en el software Oracle Data Access Components (ODAC) que se va a instalar.

Nota:

En general, se recomienda usar controladores proporcionados por Oracle en lugar de implementaciones de Microsoft, ya que es probable que los controladores anteriores estén más actualizados. Si se puede resolver un problema cambiando a un proveedor de Oracle desde una implementación de controlador de Microsoft, es una solución preferida.

Ruta de búsqueda predeterminada de .NET

A diferencia de cargar controladores ODBC y proveedores OLE DB, los proveedores de datos de .NET no se basan en el registro. En su lugar, el cargador de .NET usa una heurística de búsqueda que se describe de la siguiente manera:

  1. La DEVPATH variable de entorno se comprueba para una carpeta compartida. Solo debe usarlo al desarrollar ensamblados compartidos. Una vez completado el desarrollo, el ensamblado debe instalarse en la caché global de ensamblados (GAC).
  2. La GAC se comprueba para ver si el ensamblado se comparte entre aplicaciones. Si el ensamblado no está en la GAC, es un ensamblado privado.
  3. Si la aplicación o el archivo de configuración web tiene un elemento, el href atributo proporciona el nombre y la ruta de acceso absoluta del archivo que contiene el manifiesto del ensamblado.
  4. Se comprueba la carpeta donde está instalada la aplicación.
  5. Se comprueba una subcarpeta en la carpeta de la aplicación con el mismo nombre que el archivo que contiene el manifiesto del ensamblado.
  6. Si el archivo de configuración tiene un elemento, el privatePath atributo proporciona el nombre de una o varias subcarpetas que se van a buscar en la carpeta de la aplicación.

La heurística de búsqueda es un algoritmo de carga de DLL general. Con proveedores de .NET integrados, el archivo DLL casi siempre se encuentra en una de las siguientes carpetas:

  • C:\windows\microsoft.net\Framework (ensamblados de 32 bits)
  • C:\windows\microsoft.net\Framework64 (ensamblados de 64 bits)

En estas carpetas, habrá una carpeta para las distintas versiones de .NET. Normalmente, solo nos preocupa lo siguiente:

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

Es posible que observe las carpetas .NET 1.0 y 1.1. Estos no son compatibles y no contienen ningún ensamblado. También puede observar las carpetas .NET 3.0 y 3.5. Aunque pueden contener determinados archivos específicos de estas versiones de .NET, son todas las extensiones de la versión 2.0 y System.Data.DLL se encuentran en la carpeta 2.0, ya que no es un archivo DLL de extensión. Las carpetas mencionadas anteriormente son las ubicaciones de los archivos DLL integrados del marco de trabajo.

Además, estos archivos DLL y archivos DLL de terceros aparecen en la GAC, que es donde se ve el algoritmo de búsqueda. La GAC está en:

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

Algunos ensamblados de .NET 4.0 también se encuentran en:

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

Para obtener instrucciones más completas, consulte How the Runtime Locates Assemblies (Cómo busca ensamblados en tiempo de ejecución). El uso de PROCMON también puede revelar la ruta de búsqueda.

Proveedores de terceros

Muchos proveedores instalados por Microsoft como Analysis Services no vienen con .NET Framework. Además, hay proveedores de .NET de terceros, como el proveedor de ODP de Oracle que se instalan de forma independiente.

Para proveedores de terceros, asegúrese de que el ensamblado se encuentra en una de las siguientes carpetas y de que es de 64 o 32 bits en función de la aplicación:

  • C:\windows\microsoft.net\assembly (para versiones de .NET Framework 4.x)
  • C:\windows\assembly (para .NET Framework 2.0, 3.0, 3.1, 4.x)

En la tabla siguiente se muestran los nombres dll y ensamblado de algunos proveedores comunes:

Nombre descriptivo Nombre del ensamblado DLL
Proveedor de datos de .NET para SQL Server System.Data.SqlClient System.Data.DLL
Proveedor OLE DB System.Data.OleDb System.Data.DLL
Proveedor ODBC System.Data.Odbc System.Data.DLL
Proveedor de Analysis Services Proveedor de Analysis Services Microsoft.AnalysisServices.AdomdClient.DLL Microsoft.AnalysisServices.AdomdClient
Proveedor de SQL CE System.Data.SqlServerCe System.Data.SqlServerCe.DLL
Proveedor de Oracle de Microsoft System.Data.OracleClient System.Data.OracleClient.DLL
Proveedor de ODP de Oracle Oracle.DataAccess.Client Oracle.DataAccess.DLL

Al solucionar problemas de proveedores de .NET, no hay ninguna herramienta integrada o generalizada, como el administrador ODBC o un archivo UDL, para probar la aplicación de forma independiente. En tales casos, puede escribir una aplicación de prueba rápida en un idioma de su elección. Esta es una aplicación de ejemplo escrita en 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

Si el script se encuentra en C:\temp y desea recuperar el esquema de autenticación de un servidor denominado sqlprod01, ejecute el siguiente comando desde Windows PowerShell como administrador:

.\get-sqlauthscheme.ps1 sqlprod01

En general, cargar proveedores de .NET no será un problema si el ensamblado o dll existe. El problema más común es los problemas de autenticación, que puede probar mediante un proveedor OLE DB equivalente a través de un archivo UDL.

Para obtener ayuda con cadena de conexión para controladores desconocidos, consulte La referencia de cadenas de conexión.

Más información