Dela via

Installationskontroll för .NET-dataprovider

När du använder .NET-leverantörer i Microsoft .NET är det viktigt att förstå de olika komponenterna och deras beroenden för sömlös integrering i dina program. Den här artikeln beskriver de viktigaste aspekterna av .NET-leverantörer, deras standardsökvägar och felsökningsriktlinjer.

Kommentar

Den här artikeln beskriver inte .NET Core-installationer.

Microsoft .NET-dataprovidrar

Microsoft .NET innehåller fyra dataprovidrar som levereras med .NET Framework:

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

De första tre finns i System.Data.DLL och den sista finns i System.Data.OracleClient.DLL. När du skapar ett program behöver du bara lägga till en referens till lämplig DLL (kallas även "sammansättning") i projektet och sedan kan du använda providern.

System.Data.SqlClient innehåller implementeringskod som liknar SQL Native Client och förlitar sig inte alls på OLE DB - eller ODBC-API :er.

System.Data.Odbc och System.Data.OleDb tillhandahåller inte några inbyggda databasfunktioner. I stället läser de in ODBC-drivrutiner respektive OLE DB-providers.

System.Data.OracleClient innehåller även implementeringskod, men liksom Oracle ODBC-drivrutiner och OLE DB-leverantörer förlitar den sig också på oracle-klientprogramvaran eller Oracle Data Access Components-programvaran (ODAC) som ska installeras.

Kommentar

I allmänhet rekommenderar vi att du använder drivrutiner som tillhandahålls av Oracle i stället för Microsoft-implementeringar eftersom de tidigare drivrutinerna sannolikt är mer uppdaterade. Om ett problem kan lösas genom att byta till en Oracle-provider från en Microsoft-drivrutinsimplementering är det en prioriterad lösning.

Standardsökväg för .NET-sökning

Till skillnad från inläsning av ODBC-drivrutiner och OLE DB-leverantörer förlitar sig .NET-dataprovidrar inte på registret. I stället använder .NET-inläsaren en sök-heuristisk som beskrivs på följande sätt:

  1. Miljövariabeln DEVPATH är markerad för en delad mapp. Du bör bara använda detta när du utvecklar delade sammansättningar. När utvecklingen är klar bör sammansättningen installeras i DEN globala sammansättningscache (GAC).
  2. GAC kontrolleras för att se om sammansättningen delas mellan program. Om sammansättningen inte finns i GAC är det en privat sammansättning.
  3. Om programmet eller webbkonfigurationsfilen har ett objekt, href ger attributet namnet och den absoluta sökvägen till filen som innehåller sammansättningens manifest.
  4. Mappen där programmet är installerat är markerad.
  5. En undermapp i programmappen med samma namn som filen som innehåller sammansättningens manifest kontrolleras.
  6. Om konfigurationsfilen har ett objekt privatePath ger attributet namnet på en eller flera undermappar som ska sökas under programmappen.

Sök-heuristiken är en allmän DLL-belastningsalgoritm. Med hjälp av inbyggda .NET-providers finns DLL nästan alltid i någon av följande mappar:

  • C:\windows\microsoft.net\Framework (32-bitars sammansättningar)
  • C:\windows\microsoft.net\Framework64 (64-bitars sammansättningar)

Under dessa mappar finns det en mapp för de olika .NET-versionerna. Vanligtvis handlar det bara om:

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

Du kanske märker mapparna .NET 1.0 och 1.1. Dessa stöds inte och innehåller inga sammansättningar. Du kanske också ser mapparna .NET 3.0 och 3.5. Även om dessa kan innehålla vissa filer som är specifika för dessa versioner av .NET, är de alla tillägg till version 2.0 och System.Data.DLL finns i mappen 2.0 eftersom det inte är en tilläggs-DLL. De mappar som nämnts tidigare är platserna för de inbyggda Framework-DLL:erna.

Dessutom visas dessa DLL:er och DLL:er från tredje part i GAC, där sökalgoritmen ser ut. Gac är i:

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

Vissa .NET 4.0-sammansättningar finns också under:

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

Mer fullständiga riktlinjer finns i How the Runtime Locates Assemblies (Så här hittar Runtime sammansättningar). Användningen av PROCMON kan också visa sökvägen.

Tredjepartsleverantörer

Många Microsoft-installerade leverantörer som Analysis Services levereras inte med .NET Framework. Dessutom finns det .NET-leverantörer från tredje part, till exempel Oracles ODP-provider som installeras oberoende av varandra.

För tredjepartsleverantörer kontrollerar du att sammansättningen finns i någon av följande mappar och att den är 64-bitars eller 32-bitars beroende på programmet:

  • C:\windows\microsoft.net\assembly (för versioner av .NET Framework 4.x)
  • C:\windows\assembly (för .NET Framework 2.0, 3.0, 3.1, 4.x)

I följande tabell visas DLL- och sammansättningsnamnen för några vanliga leverantörer:

Användarvänligt namn Sammansättningsnamn DLL
.NET Data Provider för 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
Microsofts Oracle-provider System.Data.OracleClient System.Data.OracleClient.DLL
Oracles ODP-provider Oracle.DataAccess.Client Oracle.DataAccess.DLL

När du felsöker .NET-leverantörer finns det inget inbyggt eller generaliserat verktyg, till exempel ODBC-administratören eller en UDL-fil, för att testa programmet separat. I sådana fall kan du skriva ett snabbtestprogram på ett valfritt språk. Här är ett exempelprogram skrivet i 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

Om skriptet finns i C:\temp och du vill hämta autentiseringsschemat för en server med namnet sqlprod01kör du följande kommando från Windows PowerShell som administratör:

.\get-sqlauthscheme.ps1 sqlprod01

I allmänhet är inläsning av .NET-providers inte ett problem om sammansättningen/DLL finns. Det vanligaste problemet är autentiseringsproblem, som du kan testa med en motsvarande OLE DB-provider via en UDL-fil.

Hjälp med anslutningssträng för okända drivrutiner finns i Referens för anslutningssträngar.

Mer information