Bibliothèques .NET Framework prises en charge
S'applique à :SQL Server
Avec le Common Language Runtime (CLR) hébergé dans SQL Server, vous pouvez créer des procédures stockées, des déclencheurs, des fonctions définies par l’utilisateur, des types définis par l’utilisateur et des agrégats définis par l’utilisateur dans le code managé. Avec les fonctionnalités trouvées dans les bibliothèques de classes .NET Framework, vous avez accès aux classes prédéfinies qui fournissent des fonctionnalités pour la manipulation de chaînes, les opérations mathématiques avancées, l’accès aux fichiers, le chiffrement, etc. Ces classes sont accessibles à partir de procédures stockées managées, de types définis par l'utilisateur, de déclencheurs, de fonctions définies par l'utilisateur ou d'agrégats définis par l'utilisateur, quels qu'ils soient.
Si vous serviceez ou mettez à niveau des assemblys non pris en charge dans le Global Assembly Cache (GAC), votre application SQL Server peut cesser de fonctionner. Cela est dû au fait que la maintenance ou la mise à niveau des bibliothèques dans le GAC ne met pas à jour ces assemblys à l’intérieur de SQL Server. Si un assembly existe à la fois dans une base de données SQL Server et dans le GAC, les deux copies de l’assembly doivent correspondre exactement. S’ils ne correspondent pas, une erreur se produit lorsque l’assembly est utilisé par l’intégration du CLR SQL Server. Si vous effectuez un service ou mettez à niveau des assemblys du GAC qui sont également inscrits dans la base de données, y compris les assemblys .NET Framework non pris en charge, veillez également à traiter ou à mettre à niveau la copie de l’assembly à l’intérieur de vos bases de données SQL Server avec l’instruction ALTER ASSEMBLY
. Pour plus d’informations, consultez MSSQLSERVER_6522.
Bibliothèques prises en charge
SQL Server contient une liste des bibliothèques .NET Framework prises en charge qui sont testées pour s’assurer qu’elles répondent aux normes de fiabilité et de sécurité pour l’interaction avec SQL Server. Les bibliothèques prises en charge n’ont pas besoin d’être inscrites explicitement sur le serveur avant de pouvoir être utilisées dans votre code ; SQL Server les charge directement à partir du Global Assembly Cache (GAC).
Les bibliothèques/espaces de noms pris en charge par l’intégration clR dans SQL Server sont les suivants :
mscorlib.dll
CustomMarshalers.dll
Microsoft.VisualBasic.dll
Microsoft.VisualC.dll
System.Configuration.dll
System.Core.dll
System.Data.OracleClient.dll
System.Data.SqlXml.dll
System.Data.dll
System.Deployment.dll
System.Security.dll
System.Transactions.dll
System.Web.Services.dll
System.Xml.Linq.dll
system.Xml.dll
System.dll
Bibliothèques non prises en charge
Il est toujours possible d'appeler des bibliothèques non prises en charge à partir de vos procédures stockées managées, déclencheurs, fonctions définies par l'utilisateur, types définis par l'utilisateur et agrégats définis par l'utilisateur. La bibliothèque non prise en charge doit d’abord être inscrite dans la base de données SQL Server, à l’aide de l’instruction CREATE ASSEMBLY
, avant de pouvoir être utilisée dans votre code. Toute bibliothèque non prise en charge qui est inscrite et exécutée sur le serveur doit être examinée et testée en termes de sécurité et de fiabilité.
Par exemple, l’espace de noms System.DirectoryServices
n’est pas pris en charge. Vous devez inscrire l’assembly System.DirectoryServices.dll avec des autorisations UNSAFE
avant de pouvoir l’appeler à partir de votre code. L’autorisation UNSAFE
est nécessaire, car les classes de l’espace de noms System.DirectoryServices
ne répondent pas aux conditions requises pour SAFE
ou EXTERNAL_ACCESS
. Pour plus d’informations, consultez restrictions de modèle de programmation d’intégration CLR et clR integration Code Access Security.
Contenu connexe
- Créer un d’assembly
- de sécurité d’accès au code d’intégration CLR
- restrictions du modèle de programmation d’intégration CLR