Freigeben über

Installationsprüfung für .NET-Datenanbieter

Bei der Verwendung von .NET-Anbietern in Microsoft .NET ist es wichtig, die verschiedenen Komponenten und deren Abhängigkeiten für die nahtlose Integration in Ihre Anwendungen zu verstehen. In diesem Artikel werden die wesentlichen Aspekte von .NET-Anbietern, ihren Standardsuchpfaden und Richtlinien zur Problembehandlung beschrieben.

Notiz

In diesem Artikel werden .NET-Kerninstallationen nicht behandelt.

Microsoft .NET-Datenanbieter

Microsoft .NET enthält vier Datenanbieter, die mit .NET Framework ausgeliefert werden:

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

Die ersten drei sind in System.Data.DLL enthalten, und die letzte ist in System.Data.OracleClient.DLL enthalten. Beim Erstellen einer Anwendung müssen Sie ihrem Projekt nur einen Verweis auf die entsprechende DLL (auch als "Assembly" bezeichnet) hinzufügen und dann den Anbieter verwenden.

System.Data.SqlClient enthält Implementierungscode ähnlich wie SQL Native Client und basiert überhaupt nicht auf OLE DB - oder ODBC-APIs .

System.Data.Odbc und System.Data.OleDb bieten keine inhärenten Datenbankfunktionen. Stattdessen laden sie ODBC-Treiber und OLE DB-Anbieter.

System.Data.OracleClient enthält auch Implementierungscode, aber wie Oracle ODBC-Treiber und OLE DB-Anbieter verwendet er auch die Oracle Client Software oder die Zu installierende Oracle Data Access Components (ODAC)-Software.

Notiz

Im Allgemeinen wird empfohlen, dass Sie eine oracle-bereitgestellte Treiber anstelle von Microsoft-Implementierungen verwenden, da die früheren Treiber wahrscheinlich aktueller sind. Wenn ein Problem behoben werden kann, indem Sie von einer Microsoft-Treiberimplementierung zu einem Oracle-Anbieter wechseln, ist es eine bevorzugte Lösung.

Standardmäßiger .NET-Suchpfad

Im Gegensatz zum Laden von ODBC-Treibern und OLE DB-Anbietern verlassen sich die .NET-Datenanbieter nicht auf die Registrierung. Stattdessen verwendet das .NET-Ladeprogramm eine Such heuristik, die wie folgt beschrieben wird:

  1. Die Umgebungsvariable DEVPATH wird auf einen freigegebenen Ordner überprüft. Sie sollten dies nur verwenden, wenn Sie freigegebene Assemblys entwickeln. Nach Abschluss der Entwicklung sollte die Assembly im globalen Assemblycache (Global Assembly Cache, GAC) installiert werden.
  2. Das GAC wird überprüft, um festzustellen, ob die Assembly zwischen Anwendungen gemeinsam verwendet wird. Wenn sich die Assembly nicht im GAC befindet, handelt es sich um eine private Assembly.
  3. Wenn die Anwendungs- oder Webkonfigurationsdatei ein Element aufweist, erhält das href Attribut den Namen und absoluten Pfad der Datei, die das Manifest der Assembly enthält.
  4. Der Ordner, in dem die Anwendung installiert ist, wird überprüft.
  5. Ein Unterordner im Anwendungsordner mit demselben Namen wie die Datei, die das Manifest der Assembly enthält, wird überprüft.
  6. Wenn die Konfigurationsdatei über ein Element verfügt, erhält das privatePath Attribut den Namen eines oder mehrerer Unterordner, die unter dem Anwendungsordner durchsucht werden sollen.

Die Suchhuristik ist ein allgemeiner DLL-Ladealgorithmus. Bei Verwendung integrierter .NET-Anbieter befindet sich die DLL fast immer in einem der folgenden Ordner:

  • C:\windows\microsoft.net\Framework (32-Bit-Assemblys)
  • C:\windows\microsoft.net\Framework64 (64-Bit-Assemblys)

Unter diesen Ordnern gibt es einen Ordner für die verschiedenen .NET-Versionen. In der Regel beschäftigen wir uns nur mit:

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

Möglicherweise bemerken Sie die Ordner .NET 1.0 und 1.1. Diese sind nicht unterstützt und enthalten keine Assemblys. Möglicherweise stellen Sie auch die Ordner .NET 3.0 und 3.5 fest. Dies kann zwar bestimmte Dateien enthalten, die für diese Versionen von .NET spezifisch sind, aber alle Erweiterungen für Version 2.0 sind, und System.Data.DLL sich im Ordner 2.0 befindet, da es sich nicht um eine Erweiterungs-DLL handelt. Die oben erwähnten Ordner sind die Speicherorte der integrierten Framework-DLLs.

Darüber hinaus werden diese DLLs und DLLs von Drittanbietern im GAC angezeigt, wo der Suchalgorithmus aussieht. Das GAC befindet sich in:

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

Einige .NET 4.0-Assemblys befinden sich auch unter:

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

Ausführlichere Richtlinien finden Sie unter How the Runtime Locates Assemblies. Die Verwendung von PROCMON kann auch den Suchpfad anzeigen.

Drittanbieter

Viele von Microsoft installierte Anbieter wie Analysis Services sind nicht im Lieferumfang von .NET Framework enthalten. Darüber hinaus gibt es .NET-Anbieter von Drittanbietern, z. B. den ODP-Anbieter von Oracle, der unabhängig installiert wird.

Stellen Sie für Drittanbieter sicher, dass sich die Assembly in einem der folgenden Ordner befindet und je nach Anwendung 64-Bit oder 32-Bit ist:

  • C:\windows\microsoft.net\assembly (für Versionen von .NET Framework 4.x)
  • C:\windows\assembly (für .NET Framework 2.0, 3.0, 3.1, 4.x)

Die folgende Tabelle zeigt die DLL- und Assemblynamen einiger gängiger Anbieter:

Anzeigename Assemblyname DLL
.NET-Datenanbieter für SQL Server System.Data.SqlClient System.Data.DLL
OLE DB-Anbieter System.Data.OleDb System.Data.DLL
ODBC-Anbieter System.Data.Odbc System.Data.DLL
Analysis Services Provider Analysis Services Provider Microsoft.AnalysisServices.AdomdClientMicrosoft.AnalysisServices.AdomdClient.DLL
SQL CE-Anbieter System.Data.SqlServerCe System.Data.SqlServerCe.DLL
Oracle-Anbieter von Microsoft System.Data.OracleClient System.Data.OracleClient.DLL
OdP-Anbieter von Oracle Oracle.DataAccess.Client Oracle.DataAccess.DLL

Bei der Problembehandlung von .NET-Anbietern gibt es kein integriertes oder generalisiertes Tool, z. B. den ODBC-Administrator oder eine UDL-Datei, um die Anwendung unabhängig zu testen. In solchen Fällen können Sie eine Schnelltestanwendung in einer Sprache Ihrer Wahl schreiben. Hier ist eine Beispielanwendung, die in PowerShell geschrieben wurde:

#-------------------------------
#
# 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

Wenn sich Ihr Skript befindet C:\temp und Sie das Authentifizierungsschema für einen Server mit dem Namen sqlprod01abrufen möchten, führen Sie den folgenden Befehl aus Windows PowerShell als Administrator aus:

.\get-sqlauthscheme.ps1 sqlprod01

Im Allgemeinen ist das Laden von .NET-Anbietern kein Problem, wenn die Assembly/DLL vorhanden ist. Das häufigste Problem sind Authentifizierungsprobleme, die Sie mithilfe eines entsprechenden OLE DB-Anbieters über eine UDL-Datei testen können.

Hilfe zu Verbindungszeichenfolge s für unbekannte Treiber finden Sie in der Referenz zu Verbindungszeichenfolgen.

Weitere Informationen