Udostępnij za pomocą

Sprawdzanie instalacji dostawcy danych platformy .NET

W przypadku korzystania z dostawców platformy .NET na platformie Microsoft .NET ważne jest zrozumienie różnych składników i ich zależności w celu bezproblemowej integracji z aplikacjami. W tym artykule opisano podstawowe aspekty dostawców platformy .NET, ich domyślne ścieżki wyszukiwania i wskazówki dotyczące rozwiązywania problemów.

Uwaga 16.

Ten artykuł nie obejmuje instalacji platformy .NET Core.

Dostawcy danych platformy Microsoft .NET

Platforma Microsoft .NET obejmuje czterech dostawców danych dostarczanych z programem .NET Framework:

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

Pierwsze trzy znajdują się w System.Data.DLL , a ostatni znajduje się w System.Data.OracleClient.DLL. Podczas kompilowania aplikacji wystarczy dodać odwołanie do odpowiedniej biblioteki DLL (nazywanej również "zestawem"), a następnie użyć dostawcy.

System.Data.SqlClient zawiera kod implementacji podobny do natywnego klienta SQL i w ogóle nie korzysta z interfejsów API OLE DB ani ODBC .

System.Data.Odbc i System.Data.OleDb nie zapewniają żadnych nieodłącznych funkcji bazy danych. Zamiast tego ładują odpowiednio sterowniki ODBC i dostawców OLE DB.

System.Data.OracleClient zawiera również kod implementacji, ale podobnie jak sterowniki Oracle ODBC i dostawcy OLE DB, opiera się również na oprogramowaniu Oracle Client Software lub oprogramowaniu Oracle Data Access Components (ODAC) do zainstalowania.

Uwaga 16.

Ogólnie rzecz biorąc, zaleca się używanie sterowników dostarczanych przez firmę Oracle, a nie implementacji firmy Microsoft, ponieważ byłych sterowników prawdopodobnie będzie bardziej aktualny. Jeśli problem można rozwiązać, przełączając się na dostawcę Oracle z implementacji sterownika firmy Microsoft, jest to preferowane rozwiązanie.

Domyślna ścieżka wyszukiwania platformy .NET

W przeciwieństwie do ładowania sterowników ODBC i dostawców OLE DB dostawcy danych platformy .NET nie korzystają z rejestru. Zamiast tego moduł ładujący platformy .NET używa algorytmu heurystycznego wyszukiwania opisanego w następujący sposób:

  1. Zmienna DEVPATH środowiskowa jest sprawdzana pod kątem folderu udostępnionego. Należy go używać tylko podczas tworzenia udostępnionych zestawów. Po zakończeniu programowania zestaw powinien zostać zainstalowany w globalnej pamięci podręcznej zestawów (GAC).
  2. Funkcja GAC jest sprawdzana, czy zestaw jest współużytkowany między aplikacjami. Jeśli zestaw nie znajduje się w GAC, jest to zestaw prywatny.
  3. Jeśli plik konfiguracji aplikacji lub sieci Web zawiera element, href atrybut nadaje nazwę i ścieżkę bezwzględną pliku zawierającego manifest zestawu.
  4. Zaznaczono folder, w którym zainstalowano aplikację.
  5. Podfolder w folderze aplikacji o takiej samej nazwie jak plik zawierający manifest zestawu jest sprawdzany.
  6. Jeśli plik konfiguracji zawiera element, privatePath atrybut nadaje nazwę co najmniej jednego podfolderu do wyszukania w folderze aplikacji.

Heurystyka wyszukiwania jest ogólnym algorytmem ładowania bibliotek DLL. Korzystając z wbudowanych dostawców platformy .NET, biblioteka DLL jest prawie zawsze w jednym z następujących folderów:

  • C:\windows\microsoft.net\Framework (zestawy 32-bitowe)
  • C:\windows\microsoft.net\Framework64 (zestawy 64-bitowe)

W tych folderach będzie dostępny folder dla różnych wersji platformy .NET. Zazwyczaj zajmujemy się tylko:

  • wersja 2.0.50727 (.NET 2.0, 3.0, 3.5)
  • wersja 4.0.30319 (.NET 4.x)

Możesz zauważyć foldery .NET 1.0 i 1.1. Nie są one obsługiwane i nie zawierają żadnych zestawów. Można również zauważyć foldery .NET 3.0 i 3.5. Chociaż mogą one zawierać pewne pliki specyficzne dla tych wersji platformy .NET, wszystkie są rozszerzeniami w wersji 2.0, a System.Data.DLL znajduje się w folderze 2.0, ponieważ nie jest to biblioteka DLL rozszerzenia. Foldery wymienione wcześniej są lokalizacjami wbudowanych bibliotek DLL platformy.

Ponadto te biblioteki DLL i biblioteki DLL innych firm są wyświetlane w GAC, gdzie wygląda algorytm wyszukiwania. GAC jest w:

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

Niektóre zestawy platformy .NET 4.0 znajdują się również w obszarze:

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

Aby uzyskać bardziej kompletne wskazówki, zobacz How the Runtime Locates Assemblies (Jak środowisko uruchomieniowe lokalizuje zestawy). Użycie narzędzia PROCMON może również ujawnić ścieżkę wyszukiwania.

Dostawcy innych firm

Wielu dostawców zainstalowanych przez firmę Microsoft, takich jak Analysis Services, nie jest dostępnych w programie .NET Framework. Ponadto istnieją dostawcy platformy .NET innych firm, tacy jak dostawca ODP firmy Oracle, którzy są instalowani niezależnie.

W przypadku dostawców innych firm upewnij się, że zestaw znajduje się w jednym z następujących folderów i że jest 64-bitowy lub 32-bitowy w zależności od aplikacji:

  • C:\windows\microsoft.net\assembly (dla wersji programu .NET Framework 4.x)
  • C:\windows\assembly (dla programu .NET Framework 2.0, 3.0, 3.1, 4.x)

W poniższej tabeli przedstawiono nazwy bibliotek DLL i zestawów niektórych typowych dostawców:

Przyjazna nazwa Nazwa zestawu DLL
Dostawca danych .NET dla programu SQL Server System.Data.SqlClient System.Data.DLL
Dostawca OLE DB System.Data.OleDb System.Data.DLL
Dostawca ODBC System.Data.Odbc System.Data.DLL
Dostawca usług Analysis Services Dostawca usług Analysis Services Microsoft.AnalysisServices.AdomdClientMicrosoft.AnalysisServices.AdomdClient.DLL
Dostawca PROGRAMU SQL CE System.Data.SqlServerCe System.Data.SqlServerCe.DLL
Dostawca Oracle firmy Microsoft System.Data.OracleClient System.Data.OracleClient.DLL
Dostawca ODP firmy Oracle Oracle.DataAccess.Client Oracle.DataAccess.DLL

Podczas rozwiązywania problemów z dostawcami platformy .NET nie ma wbudowanego ani uogólnionego narzędzia, takiego jak administrator ODBC lub plik UDL, aby niezależnie przetestować aplikację. W takich przypadkach możesz napisać szybką aplikację testową w wybranym języku. Oto przykładowa aplikacja napisana w programie 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

Jeśli skrypt znajduje się w C:\temp lokalizacji i chcesz pobrać schemat uwierzytelniania dla serwera o nazwie sqlprod01, uruchom następujące polecenie z programu Windows PowerShell jako administrator:

.\get-sqlauthscheme.ps1 sqlprod01

Ogólnie rzecz biorąc, ładowanie dostawców platformy .NET nie będzie problemem, jeśli zestaw/biblioteka DLL istnieje. Najczęstszym problemem są problemy z uwierzytelnianiem, które można przetestować przy użyciu równoważnego dostawcy OLE DB za pośrednictwem pliku UDL.

Aby uzyskać pomoc dotyczącą parametry połączenia dla nieznanych sterowników, zobacz Dokumentację parametrów połączenia.

Więcej informacji

  • Last updated on