Diseñar ensamblados

Actualizado: 5 de diciembre de 2005

En este tema se describen los siguientes aspectos que se deben tener en cuenta al diseñar ensamblados:

• Empaquetar ensamblados
• Administrar la seguridad de los ensamblados
• Restricciones en los ensamblados

Empaquetar ensamblados

Un ensamblado puede contener funcionalidad para más de un tipo o una rutina de SQL Server en sus clases y métodos. En la mayoría de los casos, resulta conveniente empaquetar la funcionalidad de rutinas que ejecutan funciones relacionadas dentro del mismo ensamblado, especialmente si estas rutinas comparten clases cuyos métodos se llaman unos a otros. Por ejemplo, las clases que efectúan tareas de administración de entradas de datos para desencadenadores de Common Language Runtime (CLR) y procedimientos almacenados de CLR se pueden empaquetar en el mismo ensamblado. Esto se debe a que los métodos correspondientes a estas clases tienen más probabilidad de llamarse unos a otros que los de tareas menos relacionadas.

Cuando empaquete código en un ensamblado, debe tener en cuenta lo siguiente:

• Los índices y tipos definidos por el usuario CLR que dependan de funciones definidas por el usuario CLR pueden provocar que haya datos almacenados en la base de datos que dependan del ensamblado. Normalmente, modificar el código de un ensamblado resulta más complejo cuando hay datos almacenados que dependen del ensamblado de la base de datos. Por lo tanto, en general es mejor separar el código en el que se basan las dependencias de datos almacenados (como los tipos y los índices definidos por el usuario que utilizan funciones definidas por el usuario) del código que no tiene tales dependencias de datos almacenados. Para obtener más información, vea Implementar ensamblados y ALTER ASSEMBLY (Transact-SQL).
• Si parte del código administrado requiere un permiso de mayor nivel, es mejor separar ese código en un ensamblado diferente del correspondiente al código que no requiere ese nivel de permiso.

Administrar la seguridad de los ensamblados

Es posible controlar el grado de acceso de un ensamblado a los recursos protegidos mediante la seguridad de acceso a código de .NET mientras ejecuta código administrado. Para ello, tiene que especificar uno de estos tres conjuntos de permisos al crear o modificar un ensamblado: SAFE, EXTERNAL_ACCESS o UNSAFE.

SAFE

SAFE es el conjunto de permisos predeterminado y es el más restrictivo. El código ejecutado por un ensamblado con permisos SAFE no podrá tener acceso a recursos externos del sistema, como los archivos, la red, las variables de entorno o el registro. El código SAFE puede tener acceso a datos de las bases de datos locales de SQL Server o puede ejecutar cálculos y lógica de negocios que no impliquen acceso a recursos ajenos a las bases de datos locales.

La mayoría de ensamblados realizan cálculos y tareas de administración de datos sin necesidad de tener acceso a recursos ajenos a SQL Server. Por lo tanto, se recomienda SAFE como conjunto de permisos de los ensamblados.

EXTERNAL_ACCESS

EXTERNAL_ACCESS permite a los ensamblados obtener acceso a ciertos recursos externos del sistema, como los archivos, las redes, los servicios Web, las variables de entorno y el registro. Sólo los inicios de sesión de SQL Server con permisos EXTERNAL ACCESS pueden crear ensamblados con EXTERNAL_ACCESS.

Sólo los ensamblados con SAFE y EXTERNAL_ACCESS pueden incluir código con seguridad de tipos verificable. Esto significa que dichos ensamblados sólo tienen acceso a clases a través de puntos de entrada bien definidos que son válidos para la definición de tipos. Por lo tanto, no pueden tener acceso arbitrariamente a búferes de memoria que no pertenezcan al código. Además, no pueden realizar operaciones que puedan tener un efecto adverso en la estabilidad del proceso de SQL Server.

UNSAFE

UNSAFE proporciona a los ensamblados un acceso sin límites a los recursos situados tanto dentro como fuera de SQL Server. El código que se ejecuta desde un ensamblado con UNSAFE puede llamar a código no administrado.

Además, si se especifica UNSAFE, el código incluido en el ensamblado puede realizar operaciones que la comprobación de CLR considera sin seguridad de tipos. Estas operaciones pueden tener acceso a búferes de memoria en el espacio del proceso de SQL Server de forma incontrolada. Los ensamblados con UNSAFE también pueden trastornar la seguridad del sistema de SQL Server o de CLR. Los permisos UNSAFE sólo deben concederlos programadores o administradores experimentados a ensamblados de mucha confianza. Sólo pueden crear ensamblados con UNSAFE los miembros de la función fija de servidor sysadmin.

Restricciones en los ensamblados

SQL Server 2005 impone ciertas restricciones en el código administrado de los ensamblados para asegurarse de que puedan ejecutarse de manera confiable y escalable. Esto significa que, en los ensamblados con SAFE y EXTERNAL_ACCESS, no se permiten ciertas operaciones que pueden comprometer la estabilidad del servidor.

Atributos personalizados no permitidos

Los ensamblados no se pueden anotar con los siguientes atributos personalizados:

System.ContextStaticAttribute
System.MTAThreadAttribute
System.Runtime.CompilerServices.MethodImplAttribute
System.Runtime.CompilerServices.CompilationRelaxationsAttribute
System.Runtime.Remoting.Contexts.ContextAttribute
System.Runtime.Remoting.Contexts.SynchronizationAttribute
System.Runtime.InteropServices.DllImportAttribute 
System.Security.Permissions.CodeAccessSecurityAttribute
System.STAThreadAttribute
System.ThreadStaticAttribute

Además, los ensamblados con SAFE y EXTERNAL_ACCESS no se pueden anotar con los siguientes atributos personalizados:

System.Security.SuppressUnmanagedCodeSecurityAttribute
System.Security.UnverifiableCodeAttribute

API de .NET Framework no permitidas

No se puede llamar a las API .NET Framework de Microsoft que estén anotadas con uno de los HostProtectionAttributes no admitidos desde ensamblados con SAFE y EXTERNAL_ACCESS.

eSelfAffectingProcessMgmt
eSelfAffectingThreading
eSynchronization
eSharedState 
eExternalProcessMgmt
eExternalThreading
eSecurityInfrastructure
eMayLeakOnAbort
eUI

Ensamblados de .NET Framework admitidos

Cualquier ensamblado al que hace referencia su ensamblado personalizado se debe cargar en SQL Server 2005 mediante CREATE ASSEMBLY. Los siguientes ensamblados de .NET Framework ya están cargados en SQL Server y, por lo tanto, se les puede hacer referencia mediante ensamblados personalizados sin la necesidad de utilizar CREATE ASSEMBLY.

custommarshallers.dll
Microsoft.visualbasic.dll
Microsoft.visualc.dll
mscorlib.dll
system.data.dll
System.Data.SqlXml.dll
system.dll
system.security.dll
system.web.services.dll
system.xml.dll
System.Transactions
System.Data.OracleClient
System.Configuration

Vea también

Otros recursos

Ensamblados (motor de base de datos)
CLR Integration Security

Ayuda e información

Obtener ayuda sobre SQL Server 2005

Historial de cambios