CREATE ASSEMBLY (Transact-SQL)

Se aplica a:SQL ServerAzure SQL Managed Instance

Crea un módulo de aplicación administrada que contiene metadatos de clase y código administrado como un objeto en una instancia de SQL Server. Mediante este módulo, puede crear en la base de datos funciones CLR (Common Language Runtime), procedimientos almacenados, desencadenadores, funciones de agregado definidas por el usuario y tipos definidos por el usuario.

Advertencia

CLR usa la seguridad de acceso del código (CAS) de .NET Framework, que ya no se admite como un límite de seguridad. Un ensamblado CLR creado con la opción PERMISSION_SET = SAFE puede tener acceso a los recursos externos del sistema, llamar a código no administrado y adquirir privilegios sysadmin. A partir de SQL Server 2017 (14.x), se incluye una opción de sp_configure denominada clr strict security para mejorar la seguridad de los ensamblados CLR. La opción clr strict security está habilitada de forma predeterminada y trata los ensamblados SAFE y EXTERNAL_ACCESS como si estuvieran marcados con UNSAFE. La opción clr strict security se puede deshabilitar para permitir la compatibilidad con versiones anteriores, pero no se recomienda hacerlo. Microsoft recomienda que todos los ensamblados estén firmados con un certificado o clave asimétrica con el correspondiente inicio de sesión que tenga concedido el permiso UNSAFE ASSEMBLY en la base de datos maestra. Para obtener más información, vea CLR strict security.

Convenciones de sintaxis de Transact-SQL

Sintaxis

CREATE ASSEMBLY assembly_name  
[ AUTHORIZATION owner_name ]  
FROM { <client_assembly_specifier> | <assembly_bits> [ ,...n ] }  
[ WITH PERMISSION_SET = { SAFE | EXTERNAL_ACCESS | UNSAFE } ]  
[ ; ]  
<client_assembly_specifier> :: =  
        '[\\computer_name\]share_name\[path\]manifest_file_name'  
  | '[local_path\]manifest_file_name'  
  
<assembly_bits> :: =  
{ varbinary_literal | varbinary_expression }  

Argumentos

assembly_name
Es el nombre del ensamblado. El nombre debe ser único en la base de datos y un identificador válido.

AUTHORIZATION owner_name
Especifica el nombre de un usuario o rol como propietario del ensamblado. owner_name debe ser el nombre de un rol del que el usuario actual sea miembro, o bien el usuario actual debe tener el permiso IMPERSONATE sobre owner_name. Si no se especifica, la propiedad se otorga al usuario actual.

<client_assembly_specifier>
Especifica la ruta de acceso local o ubicación de red en la que se encuentra el ensamblado que se carga y, además, el nombre de archivo de manifiesto que se corresponde con el ensamblado. <client_assembly_specifier> se puede expresar como una cadena fija o una expresión que se evalúe como una cadena fija, con variables. CREATE ASSEMBLY no admite la carga de ensamblados de varios módulos. SQL Server también busca cualquier ensamblado dependiente de este ensamblado en la misma ubicación y lo carga con el mismo propietario que el ensamblado de nivel raíz. Si estos ensamblados dependientes no se encuentran o aún no están cargados en la base de datos actual, CREATE ASSEMBLY produce un error. Si los ensamblados dependientes ya están cargados en la base de datos actual, el propietario de los mismos deberá ser el mismo que el del ensamblado nuevo que se crea.

Importante

Azure SQL Database y Azure SQL Instancia administrada no admiten la creación de un ensamblado a partir de un archivo.

<client_assembly_specifier> no se puede especificar si el usuario que ha iniciado sesión es suplantado.

<assembly_bits>
Es la lista de valores binarios que forman el ensamblado y sus ensamblados dependientes. El primer valor de esta lista se considera el ensamblado raíz. Los valores correspondientes a los ensamblados dependientes pueden suministrarse en cualquier orden. Se ignora cualquier valor que no se corresponda con los ensamblados dependientes del ensamblado raíz.

Nota

Esta opción no está disponible en las bases de datos independientes.

varbinary_literal
Es un literal varbinary.

expresión_varbinary
Es una expresión de tipo varbinary.

PERMISSION_SET { SAFE | EXTERNAL_ACCESS | UNSAFE }

Importante

La opción PERMISSION_SET se ve afectada por la opción clr strict security, descrita en la advertencia inicial. Cuando clr strict security está habilitada, todos los ensamblados se tratan como UNSAFE.

Especifica un conjunto de permisos de acceso a código que se conceden al ensamblado cuando SQL Server tiene acceso al mismo. Si no se especifica, el valor SAFE se aplica de forma predeterminada.

Es recomendable el uso de SAFE. SAFE es el conjunto de permisos más restrictivo. El código que ejecuta un ensamblado con permisos SAFE no puede tener acceso a recursos externos del sistema, como archivos, la red, variables de entorno o el registro.

EXTERNAL_ACCESS habilita que los ensamblados tengan acceso a determinados recursos externos del sistema, como archivos, redes, variables de entorno y el Registro.

Nota

Esta opción no está disponible en las bases de datos independientes.

UNSAFE habilita que los ensamblados tengan acceso ilimitado a los recursos, tanto dentro como fuera de una instancia de SQL Server. El código que se ejecuta desde dentro de un ensamblado UNSAFE puede llamarse código no administrado.

Nota

Esta opción no está disponible en las bases de datos independientes.

Importante

SAFE es el ajuste de permiso recomendado para ensamblados que realizan tareas de administración de datos y cálculos sin tener acceso a los recursos fuera de una instancia de SQL Server.

Es recomendable el uso de EXTERNAL_ACCESS para ensamblados que tengan acceso a recursos fuera de una instancia de SQL Server. Los ensamblados EXTERNAL_ACCESS incluyen la protección de escalabilidad y confiabilidad ofrecida por los ensamblados SAFE; sin embargo, desde el punto de vista de la seguridad, son similares a los ensamblados UNSAFE. Esto se debe a que el código en los ensamblados EXTERNAL_ACCESS se ejecuta de forma predeterminada con la cuenta del servicio SQL Server y tiene acceso a los recursos externos con esa misma cuenta, a no ser que el código suplante al autor de la llamada de forma explícita. Por esta razón, el permiso para crear ensamblados EXTERNAL_ACCESS solo debe concederse a los inicios de sesión en los que se confíe para ejecutar código con la cuenta del servicio SQL Server. Para obtener más información sobre la suplantación, vea Seguridad de la integración CLR.

Si especifica UNSAFE, otorga libertad absoluta al código en el ensamblado para realizar operaciones en el espacio de procesos de SQL Server que pueden comprometer la solidez de SQL Server. Los ensamblados UNSAFE también pueden trastornar potencialmente el sistema de seguridad de SQL Server o de Common Language Runtime. Los permisos UNSAFE solo deben otorgarse a los ensamblados de gran confianza. Solo los miembros del rol fijo de servidor sysadmin pueden crear y modificar los ensamblados UNSAFE.

Para obtener más información sobre los conjuntos de permisos de ensamblado, vea Diseño de ensamblados.

Observaciones

CREATE ASSEMBLY carga un ensamblado que ha sido compilado anteriormente como un archivo .dll desde código administrado para su uso dentro de una instancia de SQL Server.

Cuando se habilita, la opción PERMISSION_SET en las instrucciones CREATE ASSEMBLY y ALTER ASSEMBLY se omite en tiempo de ejecución, pero las opciones PERMISSION_SET se conservan en los metadatos. Si la opción se omite, se reduce el riesgo de romper las instrucciones de código existentes.

SQL Server no permite registrar distintas versiones de un ensamblado con el mismo nombre, referencia cultural y clave pública.

Cuando se intenta obtener acceso al ensamblado especificado en <client_assembly_specifier>, SQL Server suplanta el contexto de seguridad del inicio de sesión de Windows actual. Si <client_assembly_specifier> especifica una ubicación de red (ruta de acceso UNC), la suplantación del inicio de sesión actual no se mantiene en la ubicación de red debido a las limitaciones de delegación. En este caso, el acceso se realiza mediante el contexto de seguridad de la cuenta del servicio SQL Server. Para más información, vea Credenciales (motor de base de datos).

Además del ensamblado raíz especificado por assembly_name, SQL Server intenta cargar cualquier ensamblado al que haga referencia el ensamblado raíz que se carga. Si ya se ha cargado en la base de datos un ensamblado referenciado por la existencia de una instrucción CREATE ASSEMBLY anterior, este ensamblado no se carga, sino que está disponible para el ensamblado raíz. Si no se ha cargado antes un ensamblado dependiente, pero SQL Server no puede localizar el archivo de manifiesto en el directorio de origen, CREATE ASSEMBLY produce un error.

Si un ensamblado dependiente referenciado por el ensamblado raíz no está aún en la base de datos y se ha cargado implícitamente junto con el ensamblado raíz, este ensamblado tiene establecidos los mismos permisos que el ensamblado raíz. Si se deben crear ensamblados dependientes mediante el uso de permisos diferentes de los del ensamblado raíz, estos deben cargarse explícitamente antes del ensamblado raíz con los permisos apropiados establecidos.

Validación del ensamblado

SQL Server realiza comprobaciones en los binarios del ensamblado cargados mediante la instrucción CREATE ASSEMBLY para garantizar que lo siguiente se cumple:

  • El binario del ensamblado está formado por metadatos y segmentos de código válidos; los segmentos de código tienen instrucciones MSIL (Lenguaje intermedio de Microsoft) válidas.

  • El conjunto de ensamblados del sistema al que se hace referencia es uno de los siguientes ensamblados admitidos en SQL Server: Microsoft.Visualbasic.dll, Mscorlib.dll, System.Data.dll, System.dll, System.Xml.dll, Microsoft.Visualc.dll, Custommarshallers.dll, System.Security.dll, System.Web.Services.dll, System.Data.SqlXml.dll, System.Core.dll y System.Xml.Linq.dll. Se puede hacer referencia a otros ensamblados del sistema, pero deben estar registrados de forma explícita en la base de datos.

  • Para ensamblados creados mediante los conjuntos de permisos SAFE o EXTERNAL ACCESS:

    • El código del ensamblado debe tener seguridad de tipos. La seguridad de tipos se establece ejecutando el comprobador de Common Language Runtime en el ensamblado.

    • El ensamblado no debe contener ningún miembro de datos estáticos en sus clases, a menos que esté marcado como de solo lectura.

    • Las clases en el ensamblado no pueden contener métodos de finalizador.

    • Las clases o métodos del ensamblado deben anotarse solamente con atributos de código permitidos. Para obtener más información, vea Atributos personalizados para las rutinas CLR.

Además de las comprobaciones previas realizadas al ejecutar CREATE ASSEMBLY, existen comprobaciones adicionales que se realizan en el tiempo de ejecución del código en el ensamblado:

  • Se puede producir un error en la llamada a determinadas API de Microsoft .NET Framework que requieren un permiso de acceso a código específico si el conjunto de permisos del ensamblado no incluye ese permiso.

  • En el caso de ensamblados SAFE y EXTERNAL_ACCESS, cualquier intento de llamada a las API .NET Framework anotadas con HostProtectionAttributes dará error.

Para obtener más información, vea Diseño de ensamblados.

Permisos

Requiere el permiso CREATE ASSEMBLY.

Si se especifica PERMISSION_SET = EXTERNAL_ACCESS, se requiere el permiso EXTERNAL ACCESS ASSEMBLY en el servidor. Si se especifica PERMISSION_SET = UNSAFE, se requiere el permiso UNSAFE ASSEMBLY en el servidor.

El usuario debe ser el propietario de cualquier ensamblado al que el ensamblado que se va a cargar haga referencia (si los ensamblados ya existen en la base de datos). Para cargar un ensamblado mediante una ruta de acceso de archivo, el usuario actual debe ser miembro del inicio de sesión autenticado de Windows o del rol fijo de servidor sysadmin. El inicio de sesión de Windows del usuario que ejecuta CREATE ASSEMBLY debe tener permisos de lectura en el recurso compartido y en los archivos que se cargan por medio de la instrucción.

Permisos con seguridad estricta de CLR

Los siguientes permisos son necesarios para crear un ensamblado CLR cuando la opción CLR strict security está habilitada:

  • El usuario debe tener el permiso CREATE ASSEMBLY.
  • Y una de las siguientes condiciones también debe ser cierta:
    • El ensamblado debe estar firmado con un certificado o clave asimétrica que tenga el inicio de sesión correspondiente con el permiso UNSAFE ASSEMBLY en el servidor. Se recomienda firmar el ensamblado.
    • La base de datos tiene la propiedad TRUSTWORTHY establecida en ON y pertenece a un inicio de sesión que tiene el permiso UNSAFE ASSEMBLY en el servidor. Esta opción no se recomienda.

Para obtener más información sobre los conjuntos de permisos de ensamblado, vea Diseño de ensamblados.

Ejemplos

Ejemplo A: creación de un ensamblado desde un archivo dll

Se aplica a: SQL Server 2008 (10.0.x) y versiones posteriores.

En el ejemplo siguiente se asume que los ejemplos del Motor de base de datos de SQL Server se han instalado en la ubicación predeterminada del equipo local y que la aplicación de ejemplo HelloWorld.csproj se ha compilado. Para más información, vea Ejemplo de Hola a todos.

CREATE ASSEMBLY HelloWorld   
FROM '<system_drive>:\Program Files\Microsoft SQL Server\100\Samples\HelloWorld\CS\HelloWorld\bin\debug\HelloWorld.dll'  
WITH PERMISSION_SET = SAFE;  

Importante

Azure SQL Database no admite la creación de un ensamblado desde un archivo.

Ejemplo B: creación de un ensamblado a partir de bits de ensamblado

Se aplica a: SQL Server 2008 (10.0.x) y versiones posteriores.

Reemplace los bits de ejemplo (que no son completos o válidos) con sus bits de ensamblado.

CREATE ASSEMBLY HelloWorld  
    FROM 0x4D5A900000000000  
WITH PERMISSION_SET = SAFE;  

Consulte también

ALTER ASSEMBLY (Transact-SQL)
DROP ASSEMBLY (Transact-SQL)
CREATE FUNCTION (Transact-SQL)
CREATE PROCEDURE (Transact-SQL)
CREATE TRIGGER (Transact-SQL)
CREATE TYPE (Transact-SQL)
CREATE AGGREGATE (Transact-SQL)
EVENTDATA (Transact-SQL)
Escenarios de uso y ejemplos para la integración de Common Language Runtime (CLR)