Note
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier les répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de changer de répertoire.
Lorsque vous utilisez des fournisseurs .NET dans Microsoft .NET, il est essentiel de comprendre les différents composants et leurs dépendances pour une intégration transparente dans vos applications. Cet article décrit les aspects essentiels des fournisseurs .NET, leurs chemins de recherche par défaut et les instructions de résolution des problèmes.
Note
Cet article ne couvre pas les installations .NET Core.
Fournisseurs de données Microsoft .NET
Microsoft .NET inclut quatre fournisseurs de données fournis avec le .NET Framework :
- System.Data.SqlClient
- System.Data.Odbc
- System.Data.OleDb
- System.Data.OracleClient
Les trois premiers sont contenus dans System.Data.DLL et le dernier est contenu dans System.Data.OracleClient.DLL. Lors de la génération d’une application, vous devez uniquement ajouter une référence à la DLL appropriée (également appelée « assembly ») à votre projet, puis vous pouvez utiliser le fournisseur.
System.Data.SqlClient contient du code d’implémentation similaire à SQL Native Client et ne s’appuie pas sur des API OLE DB ou ODBC du tout.
System.Data.Odbc et System.Data.OleDb ne fournissent aucune fonctionnalité de base de données inhérente. Au lieu de cela, ils chargent les pilotes ODBC et les fournisseurs OLE DB, respectivement.
System.Data.OracleClient contient également du code d’implémentation, mais comme les pilotes ORACLE ODBC et les fournisseurs OLE DB, il s’appuie également sur le logiciel client Oracle ou sur le logiciel ODAC (Oracle Data Access Components) à installer.
Note
En général, il est recommandé d’utiliser des pilotes fournis par Oracle plutôt que des implémentations Microsoft, car les anciens pilotes sont susceptibles d’être plus à jour. Si un problème peut être résolu en basculant vers un fournisseur Oracle à partir d’une implémentation de pilote Microsoft, il s’agit d’une solution préférée.
Chemin de recherche .NET par défaut
Contrairement au chargement des pilotes ODBC et des fournisseurs OLE DB, les fournisseurs de données .NET ne s’appuient pas sur le Registre. Au lieu de cela, le chargeur .NET utilise une heuristique de recherche décrite comme suit :
- La
DEVPATHvariable d’environnement est vérifiée pour un dossier partagé. Vous devez l’utiliser uniquement lors du développement d’assemblys partagés. Une fois le développement terminé, l’assembly doit être installé dans le Global Assembly Cache (GAC). - Le GAC est vérifié pour voir si l’assembly est partagé entre les applications. Si l’assembly n’est pas dans le GAC, il s’agit d’un assembly privé.
- Si l’application ou le fichier de configuration web a un élément, l’attribut
hrefdonne le nom et le chemin absolu du fichier contenant le manifeste de l’assembly. - Le dossier où l’application est installée est coché.
- Un sous-dossier dans le dossier d’application portant le même nom que le fichier contenant le manifeste de l’assembly est vérifié.
- Si le fichier de configuration a un élément, l’attribut
privatePathdonne le nom d’un ou plusieurs sous-dossiers à rechercher sous le dossier de l’application.
L’heuristique de recherche est un algorithme de chargement DLL général. À l’aide de fournisseurs .NET intégrés, la DLL se trouve presque toujours dans l’un des dossiers suivants :
- C :\windows\microsoft.net\Framework (assemblys 32 bits)
- C :\windows\microsoft.net\Framework64 (assemblys 64 bits)
Sous ces dossiers, il y aura un dossier pour les différentes versions de .NET. En règle générale, nous nous soucions uniquement des points suivants :
- v2.0.50727 (.NET 2.0, 3.0, 3.5)
- v4.0.30319 (.NET 4.x)
Vous remarquerez peut-être les dossiers .NET 1.0 et 1.1. Ils ne sont pas pris en charge et ne contiennent pas d’assemblys. Vous pouvez également remarquer les dossiers .NET 3.0 et 3.5. Bien que ces fichiers contiennent certains fichiers spécifiques à ces versions de .NET, ils sont toutes les extensions de la version 2.0 et System.Data.DLL se trouve dans le dossier 2.0, car il ne s’agit pas d’une DLL d’extension. Les dossiers mentionnés précédemment sont les emplacements des DLL intégrées framework.
En outre, ces DLL et dll tierces apparaissent dans le GAC, c’est-à-dire à l’endroit où l’algorithme de recherche ressemble. Le GAC est dans :
- C :\windows\assembly (pour .NET Framework 2.0, 3.0, 3.1, 4.x).
Certains assemblys .NET 4.0 se trouvent également sous :
- C :\windows\microsoft.net\assembly.
Pour obtenir des instructions plus complètes, consultez Comment le runtime localise les assemblys. L’utilisation de PROCMON peut également révéler le chemin de recherche.
Fournisseurs tiers
De nombreux fournisseurs installés par Microsoft comme Analysis Services ne sont pas fournis avec le .NET Framework. En outre, il existe des fournisseurs .NET tiers, tels que le fournisseur ODP d’Oracle qui sont installés indépendamment.
Pour les fournisseurs tiers, vérifiez que l’assembly se trouve dans l’un des dossiers suivants et qu’il est 64 bits ou 32 bits en fonction de l’application :
- C :\windows\microsoft.net\assembly (pour les versions de .NET Framework 4.x)
- C :\windows\assembly (pour .NET Framework 2.0, 3.0, 3.1, 4.x)
Le tableau suivant présente les noms de DLL et d’assembly de certains fournisseurs courants :
| Nom convivial | Nom de l'assembly | DLL |
|---|---|---|
| Fournisseur de données .NET pour SQL Server | System.Data.SqlClient | System.Data.DLL |
| Fournisseur OLE DB | System.Data.OleDb | System.Data.DLL |
| Fournisseur ODBC | System.Data.Odbc | System.Data.DLL |
| Fournisseur Analysis Services | Fournisseur Analysis Services | Microsoft.AnalysisServices.AdomdClientMicrosoft.AnalysisServices.AdomdClient.DLL |
| Fournisseur SQL CE | System.Data.SqlServerCe | System.Data.SqlServerCe.DLL |
| Fournisseur Oracle de Microsoft | System.Data.OracleClient | System.Data.OracleClient.DLL |
| Fournisseur ODP d’Oracle | Oracle.DataAccess.Client | Oracle.DataAccess.DLL |
Lors de la résolution des problèmes de fournisseurs .NET, il n’existe aucun outil intégré ou généralisé, tel que l’administrateur ODBC ou un fichier UDL, pour tester l’application indépendamment. Dans ce cas, vous pouvez écrire une application de test rapide dans une langue de votre choix. Voici un exemple d’application écrite dans 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
Si votre script se trouve C:\temp et que vous souhaitez récupérer le schéma d’authentification d’un serveur nommé sqlprod01, exécutez la commande suivante à partir de Windows PowerShell en tant qu’administrateur :
.\get-sqlauthscheme.ps1 sqlprod01
En général, le chargement des fournisseurs .NET ne sera pas un problème si l’assembly/DLL existe. Le problème le plus courant est les problèmes d’authentification, que vous pouvez tester à l’aide d’un fournisseur OLE DB équivalent via un fichier UDL.
Pour obtenir de l’aide sur les chaîne de connexion pour les pilotes inconnus, consultez la référence des chaînes de connexion.