Supported .NET Framework Libraries
With the common language runtime (CLR) hosted in SQL Server, you can author stored procedures, triggers, user-defined functions, user-defined types, and user-defined aggregates in managed code. With the functionality found in the .NET Framework class libraries, you have access to pre-built classes that provide functionality for string manipulation, advanced math operations, file access, cryptography, and more. These classes can be accessed from any managed stored procedure, user-defined type, trigger, user-defined function, or user-defined aggregate.
Note
If you service or upgrade unsupported assemblies in the global assembly cache (GAC), your SQL Server. If an assembly exists both in a SQL Server CLR integration. If you service or upgrade any assemblies in the GAC that are also registered in the database, including unsupported .NET Framework assemblies, make sure to also service or upgrade the copy of the assembly inside your SQL Server databases with the ALTER ASSEMBLY
statement. For more information, see Knowledge Base article 949080.
Supported Libraries
Beginning with SQL Server has a list of supported .NET Framework libraries, which have been tested to ensure that they meet reliability and security standards for interaction with SQL Server loads them directly from the Global Assembly Cache (GAC).
The libraries/namespaces supported by CLR integration in SQL Server are:
CustomMarshalers
Microsoft.VisualBasic
Microsoft.VisualC
mscorlib
System
System.Configuration
System.Data
System.Data.OracleClient
System.Data.SqlXml
System.Deployment
System.Security
System.Transactions
System.Web.Services
System.Xml
System.Core.dll
System.Xml.Linq.dll
Unsupported Libraries
Unsupported libraries can still be called from your managed stored procedures, triggers, user-defined functions, user-defined types, and user-defined aggregates. The unsupported library must first be registered in the SQL Server database, using the CREATE ASSEMBLY
statement, before it can be used in your code. Any unsupported library that is registered and run on the server should be reviewed and tested for security and reliability.
For example, the System.DirectoryServices
namespace is not supported. You must register the System.DirectoryServices.dll assembly with UNSAFE
permissions before you can call it from your code. The UNSAFE
permission is necessary because classes in the System.DirectoryServices
namespace do not meet the requirements for SAFE
or EXTERNAL_ACCESS
. For more information, see CLR Integration Programming Model Restrictions and CLR Integration Code Access Security.
See Also
Creating an Assembly
CLR Integration Code Access Security
CLR Integration Programming Model Restrictions