Implementing Assemblies
This topic provides information about the following areas to help you implement and work with assemblies in the database:
Creating assemblies
Modifying assemblies
Dropping, disabling, and enabling assemblies
Managing assembly versions
Creating Assemblies
Assemblies are created in SQL Server by using the Transact-SQL CREATE ASSEMBLY statement, or in the SQL Server Management Studio by using the Assembly Assisted Editor. Additionally, deploying a SQL Server Project in Microsoft Visual Studio registers an assembly in the database that was specified for the project. For more information, see Deploying CLR Database Objects.
To create an assembly by using Transact-SQL
To create an assembly by using SQL Server Management Studio
Modifying Assemblies
Assemblies are modified in SQL Server by using the Transact-SQL ALTER ASSEMBLY statement or in SQL Server Management Studio by using the Assembly Assisted Editor. You can modify an assembly when you want to do the following:
Change the implementation of the assembly by uploading a newer version of the binaries of the assembly. For more information, see Managing Assembly Versions later in this topic.
Change the permission set of the assembly. For more information, see Designing Assemblies.
Change the visibility of the assembly. Visible assemblies are available for referencing in SQL Server. Nonvisible assemblies are not available, even if they have been uploaded in the database. By default, assemblies uploaded to an instance of SQL Server are visible.
Add or drop a debug or source file associated with the assembly.
To modify an assembly by using Transact-SQL
To modify an assembly by using SQL Server Management Studio
Dropping, Disabling, and Enabling Assemblies
Assemblies are dropped by using the Transact-SQL DROP ASSEMBLY statement or SQL Server Management Studio.
To drop an assembly by using Transact-SQL
To drop an assembly by using SQL Server Management Studio
By default, all assemblies that are created in SQL Server are disabled from executing. You can use the clr enabled option of the sp_configure system stored procedure to disable or enable the execution of all assemblies that are uploaded in SQL Server. Disabling assembly execution prevents common language runtime (CLR) functions, stored procedures, triggers, aggregates, and user-defined types from executing, and stops those that are currently executing. Disabling assembly execution does not disable the ability to create, alter, or drop assemblies. For more information, see clr enabled Option.
To disable and enable assembly execution
Managing Assembly Versions
When an assembly is uploaded to an instance SQL Server, the assembly is stored and managed within the database system catalogs. Any changes made to the definition of the assembly in the Microsoft .NET Framework should be propagated to the assembly that is stored in the database catalog.
When you have to modify an assembly, you must issue an ALTER ASSEMBLY statement to update the assembly in the database. This will update the assembly to the latest copy of .NET Framework modules holding its implementation.
The WITH UNCHECKED DATA clause of the ALTER ASSEMBLY statement instructs SQL Server to refresh even those assemblies upon which persisted data in the database is dependent. Specifically, you must specify WITH UNCHECKED DATA if any of the following exist:
Persisted computed columns that reference methods in the assembly, either directly, or indirectly, through Transact-SQL functions or methods.
Columns of a CLR user-defined type that depend on the assembly, and the type implements a UserDefined (non-Native) serialization format.
Warning
If WITH UNCHECKED DATA is not specified, SQL Server tries to prevent ALTER ASSEMBLY from executing if the new assembly version affects existing data in tables, indexes, or other persistent sites. However, SQL Server does not guarantee that computed columns, indexes, indexed views, or expressions will be consistent with the underlying routines and types when the CLR assembly is updated. Be careful when you execute ALTER ASSEMBLY to make sure that there is no mismatch between the result of an expression and a value that is based on that expression stored in the assembly.
Only members of the db_owner and db_ddlowner fixed database role can execute run ALTER ASSEMBLY by using the WITH UNCHECKED DATA clause.
SQL Server posts a message to the Windows application event log that the assembly has been modified with unchecked data in the tables. SQL Server then marks any tables that contain data dependent on the assembly as having unchecked data. The has_unchecked_assembly_data column of the sys.tables catalog view contains the value 1 for tables that contain unchecked data, and 0 for tables without unchecked data.
To resolve the integrity of unchecked data, run DBCC CHECKTABLE against each table that has unchecked data. If DBCC CHECKTABLE fails, you must either delete the table rows that are not valid or modify the assembly code to address problems, and then issue additional ALTER ASSEMBLY statements.
ALTER ASSEMBLY changes the assembly version. The culture and public key token of the assembly remain the same. SQL Server does not allow registering different versions of an assembly with the same name, culture and public key.
Interactions with Computer-wide Policy for Version Binding
If references to assemblies stored in SQL Server are redirected to specific versions by using publisher policy or computer-wide administrator policy, you must do either of the following:
Make sure the new version to which this redirection is made is in the database.
Modify any statements to the external policy files of the computer or publisher policy to make sure that they reference the specific version that is in the database.
Otherwise, an attempt to load a new assembly version to the instance of SQL Server will fail.
To update the version of an assembly