Compartilhar via

Verificação de instalação do provedor de dados .NET

Ao usar provedores .NET no Microsoft .NET, é crucial entender os vários componentes e suas dependências para uma integração perfeita em seus aplicativos. Este artigo descreve os aspectos essenciais dos provedores .NET, seus caminhos de pesquisa padrão e diretrizes de solução de problemas.

Observação

Este artigo não aborda instalações do .NET Core.

Provedores de dados Microsoft .NET

O Microsoft .NET inclui quatro provedores de dados que são fornecidos com o .NET Framework:

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

Os três primeiros estão contidos em System.Data.DLL e o último está contido em System.Data.OracleClient.DLL. Ao criar um aplicativo, você só precisa adicionar uma referência à DLL apropriada (também conhecida como "assembly") ao seu projeto e, em seguida, pode usar o provedor.

System.Data.SqlClient contém código de implementação semelhante ao SQL Native Client e não depende de APIs OLE DB ou ODBC .

System.Data.Odbc e System.Data.OleDb não fornecem nenhuma funcionalidade de banco de dados inerente. Em vez disso, eles carregam drivers ODBC e provedores OLE DB, respectivamente.

System.Data.OracleClient também contém código de implementação, mas, como os drivers ODBC da Oracle e os provedores OLE DB, ele também depende do software Oracle Client ou do software Oracle Data Access Components (ODAC) a ser instalado.

Observação

Em geral, é recomendável que você use drivers fornecidos pela Oracle em vez de implementações da Microsoft, pois os drivers anteriores provavelmente estarão mais atualizados. Se um problema puder ser resolvido alternando para um provedor Oracle de uma implementação de driver da Microsoft, é uma solução preferencial.

Caminho de pesquisa padrão do .NET

Ao contrário do carregamento de drivers ODBC e provedores OLE DB, os provedores de dados .NET não dependem do registro. Em vez disso, o carregador do .NET usa uma heurística de pesquisa descrita da seguinte maneira:

  1. A DEVPATH variável de ambiente é verificada para uma pasta compartilhada. Você só deve usar isso ao desenvolver assemblies compartilhados. Depois que o desenvolvimento for concluído, o assembly deverá ser instalado no GAC (Cache de Assembly Global).
  2. O GAC é verificado para ver se o assembly é compartilhado entre aplicativos. Se o assembly não estiver no GAC, será um assembly privado.
  3. Se o aplicativo ou o arquivo de configuração da Web tiver um item, o href atributo fornecerá o nome e o caminho absoluto do arquivo que contém o manifesto do assembly.
  4. A pasta onde o aplicativo está instalado é verificada.
  5. Uma subpasta na pasta do aplicativo com o mesmo nome do arquivo que contém o manifesto do assembly é verificada.
  6. Se o arquivo de configuração tiver um item, o privatePath atributo fornecerá o nome de uma ou mais subpastas a serem pesquisadas na pasta do aplicativo.

A heurística de pesquisa é um algoritmo geral de carregamento de DLL. Usando provedores .NET internos, a DLL está quase sempre em uma das seguintes pastas:

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

Nessas pastas, haverá uma pasta para as várias versões do .NET. Normalmente, estamos preocupados apenas com:

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

Você pode observar as pastas .NET 1.0 e 1.1. Eles estão sem suporte e não contêm assemblies. Você também pode observar as pastas .NET 3.0 e 3.5. Embora eles possam conter determinados arquivos específicos para essas versões do .NET, todos eles são extensões da versão 2.0 e System.Data.DLL está localizado na pasta 2.0, pois não é uma DLL de extensão. As pastas mencionadas anteriormente são os locais das DLLs internas do Framework.

Além disso, essas DLLs e DLLs de terceiros aparecem no GAC, que é onde o algoritmo de pesquisa procura. O GAC está em:

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

Alguns assemblies do .NET 4.0 também estão localizados em:

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

Para obter diretrizes mais completas, consulte Como o runtime localiza assemblies. O uso do PROCMON também pode revelar o caminho da pesquisa.

Provedores de terceiros

Muitos provedores instalados pela Microsoft, como o Analysis Services, não vêm com o .NET Framework. Além disso, existem provedores .NET de terceiros, como o provedor ODP da Oracle, que são instalados de forma independente.

Para provedores de terceiros, verifique se o assembly está localizado em uma das seguintes pastas e se é de 64 bits ou 32 bits, dependendo do aplicativo:

  • C:\windows\microsoft.net\assembly (para versões do .NET Framework 4.x)
  • C:\windows\assembly (para .NET Framework 2.0, 3.0, 3.1, 4.x)

A tabela a seguir mostra os nomes de DLL e assembly de alguns provedores comuns:

Nome amigável Nome do assembly DLL
Provedor de Dados .Net para SQL Server System.Data.SqlClient System.Data.DLL
Provedor OLE DB System.Data.OleDb System.Data.DLL
Provedor ODBC System.Data.Odbc System.Data.DLL
Provedor do Analysis Services Provedor do Analysis Services Microsoft.AnalysisServices.AdomdClientMicrosoft.AnalysisServices.AdomdClient.DLL
Provedor SQL CE System.Data.SqlServerCe System.Data.SqlServerCe.DLL
Provedor Oracle da Microsoft System.Data.OracleClient System.Data.OracleClient.DLL
Provedor de ODP da Oracle Oracle.DataAccess.Client Oracle.DataAccess.DLL

Ao solucionar problemas de provedores .NET, não há nenhuma ferramenta interna ou generalizada, como o Administrador ODBC ou um arquivo UDL, para testar o aplicativo de forma independente. Nesses casos, você pode escrever um aplicativo de teste rápido em um idioma de sua escolha. Aqui está um aplicativo de exemplo escrito no 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 o script estiver localizado em C:\temp e você quiser recuperar o esquema de autenticação de um servidor chamado sqlprod01, execute o seguinte comando no Windows PowerShell como administrador:

.\get-sqlauthscheme.ps1 sqlprod01

Em geral, carregar provedores .NET não será um problema se o assembly/DLL existir. O problema mais comum são os problemas de autenticação, que você pode testar usando um provedor OLE DB equivalente por meio de um arquivo UDL.

Para obter ajuda com cadeias de conexão para drivers desconhecidos, consulte A referência de cadeias de conexão.

Mais informações