Delen via

Installatiecontrole van .NET-gegevensprovider

Wanneer u .NET-providers in Microsoft .NET gebruikt, is het essentieel om inzicht te hebben in de verschillende onderdelen en hun afhankelijkheden voor naadloze integratie in uw toepassingen. Dit artikel bevat een overzicht van de essentiële aspecten van .NET-providers, hun standaardzoekpaden en richtlijnen voor probleemoplossing.

Notitie

Dit artikel heeft geen betrekking op .NET Core-installaties.

Microsoft .NET-gegevensproviders

Microsoft .NET bevat vier gegevensproviders die worden geleverd met .NET Framework:

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

De eerste drie zijn opgenomen in System.Data.DLL en de laatste is opgenomen in System.Data.OracleClient.DLL. Wanneer u een toepassing bouwt, hoeft u alleen een verwijzing naar de juiste DLL (ook wel assembly genoemd) toe te voegen aan uw project en vervolgens kunt u de provider gebruiken.

System.Data.SqlClient bevat implementatiecode die lijkt op SQL Native Client en vertrouwt helemaal niet op OLE DB - of ODBC-API's .

System.Data.Odbc en System.Data.OleDb bieden geen inherente databasefunctionaliteit. In plaats daarvan laden ze RESPECTIEVELIJK ODBC-stuurprogramma's en OLE DB-providers.

System.Data.OracleClient bevat ook implementatiecode, maar zoals Oracle ODBC-stuurprogramma's en OLE DB-providers, is ook afhankelijk van de Oracle-clientsoftware of de ODAC-software (Oracle Data Access Components) die moet worden geïnstalleerd.

Notitie

Over het algemeen is het raadzaam om een door Oracle geleverde stuurprogramma's te gebruiken in plaats van Microsoft-implementaties, omdat de voormalige stuurprogramma's waarschijnlijk meer up-to-date zijn. Als een probleem kan worden opgelost door over te schakelen naar een Oracle-provider vanuit een Implementatie van een Microsoft-stuurprogramma, is dit een voorkeursoplossing.

Standaard .NET-zoekpad

In tegenstelling tot het laden van ODBC-stuurprogramma's en OLE DB-providers zijn de .NET-gegevensproviders niet afhankelijk van het register. In plaats daarvan gebruikt het .NET-laadprogramma een zoek-heuristiek die als volgt wordt beschreven:

  1. De DEVPATH omgevingsvariabele wordt gecontroleerd op een gedeelde map. U moet dit alleen gebruiken bij het ontwikkelen van gedeelde assembly's. Zodra de ontwikkeling is voltooid, moet de assembly worden geïnstalleerd in de Global Assembly Cache (GAC).
  2. De GAC wordt gecontroleerd om te zien of de assembly wordt gedeeld tussen toepassingen. Als de assembly zich niet in de GAC bevindt, is het een privéassembly.
  3. Als het toepassings- of webconfiguratiebestand een item bevat, geeft het href kenmerk de naam en het absolute pad van het bestand met het manifest van de assembly.
  4. De map waarin de toepassing is geïnstalleerd, wordt gecontroleerd.
  5. Een submap in de toepassingsmap met dezelfde naam als het bestand met het manifest van de assembly wordt gecontroleerd.
  6. Als het configuratiebestand een item bevat, geeft het privatePath kenmerk de naam van een of meer submappen die moeten worden doorzocht onder de toepassingsmap.

De zoek heuristiek is een algemeen DLL-belastingsalgoritmen. Met behulp van ingebouwde .NET-providers bevindt het DLL-bestand zich bijna altijd in een van de volgende mappen:

  • C:\windows\microsoft.net\Framework (32-bits assembly's)
  • C:\windows\microsoft.net\Framework64 (64-bits assembly's)

Onder deze mappen is er een map voor de verschillende .NET-versies. Normaal gesproken hebben we alleen betrekking op:

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

U ziet mogelijk de mappen .NET 1.0 en 1.1. Deze zijn niet ondersteund en bevatten geen assembly's. U ziet mogelijk ook de mappen .NET 3.0 en 3.5. Hoewel deze mogelijk bepaalde bestanden bevatten die specifiek zijn voor deze versies van .NET, zijn ze allemaal extensies naar versie 2.0 en System.Data.DLL zich in de map 2.0 bevindt, omdat het geen extensie-DLL is. De eerder genoemde mappen zijn de locaties van de ingebouwde Framework-DLL's.

Bovendien worden deze DLL's en DLL's van derden weergegeven in de GAC, waar het zoekalgoritme eruitziet. De GAC bevindt zich in:

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

Sommige .NET 4.0-assembly's bevinden zich ook onder:

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

Zie Hoe de runtime assembly's zoekt voor meer volledige richtlijnen. Het gebruik van PROCMON kan ook het zoekpad onthullen.

Externe providers

Veel door Microsoft geïnstalleerde providers, zoals Analysis Services, worden niet geleverd met .NET Framework. Daarnaast zijn er externe .NET-providers, zoals de ODP-provider van Oracle, die onafhankelijk van elkaar worden geïnstalleerd.

Voor externe providers moet u ervoor zorgen dat de assembly zich in een van de volgende mappen bevindt en dat deze 64-bits of 32-bits is, afhankelijk van de toepassing:

  • C:\windows\microsoft.net\assembly (voor versies van .NET Framework 4.x)
  • C:\windows\assembly (voor .NET Framework 2.0, 3.0, 3.1, 4.x)

In de volgende tabel ziet u de DLL- en assemblynamen van enkele algemene providers:

Beschrijvende naam Assembly-naam DLL
.NET-gegevensprovider voor SQL Server System.Data.SqlClient System.Data.DLL
OLE DB-provider 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
Oracle-provider van Microsoft System.Data.OracleClient System.Data.OracleClient.DLL
ODP-provider van Oracle Oracle.DataAccess.Client Oracle.DataAccess.DLL

Bij het oplossen van problemen met .NET-providers is er geen ingebouwd of gegeneraliseerd hulpprogramma, zoals de ODBC-beheerder of een UDL-bestand, om de toepassing onafhankelijk te testen. In dergelijke gevallen kunt u een snelle testtoepassing schrijven in een taal van uw keuze. Hier volgt een voorbeeldtoepassing die is geschreven 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

Als uw script zich bevindt C:\temp en u het verificatieschema voor een server met de naam sqlprod01wilt ophalen, voert u de volgende opdracht uit vanuit Windows PowerShell als beheerder:

.\get-sqlauthscheme.ps1 sqlprod01

Over het algemeen is het laden van .NET-providers geen probleem als de assembly/DLL bestaat. Het meest voorkomende probleem is verificatieproblemen, die u kunt testen met behulp van een equivalente OLE DB-provider via een UDL-bestand.

Zie de naslaginformatie over verbindingsreeksen voor hulp bij verbindingsreeks s voor onbekende stuurprogramma's.

Meer informatie