Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
В этом разделе описываются следующие факторы, которые следует учитывать при разработке сборок.
компоновка сборок;
управление безопасностью сборок;
ограничения на сборки.
Упаковка сборок
Сборка может содержать функции для нескольких подпрограмм SQL Server или ввести их классы и методы. В большинстве случаев имеет смысл компоновать в одну сборку функциональность подпрограмм, выполняющих связанные функции, особенно если данные подпрограммы относятся к классам, методы которых вызывают друг друга. Например, классы, выполняющие задачи по управлению вводом данных для триггеров и хранимых процедур среды CLR, могут быть скомпонованы в одной сборке. Это связано с тем, что методы для этих классов чаще вызывают друг друга, чем те из менее связанных задач.
При упаковке кода в сборку следует учитывать следующее:
Определяемые пользователем типы данных CLR и индексы, зависящие от определяемых пользователем функций среды CLR, могут вызвать появление в базе данных материализованных данных, зависящих от сборки. Изменение кода сборки часто сложнее при сохранении данных, зависящих от сборки в базе данных. Поэтому обычно лучше отделять код, от которого зависят сохраненные зависимости данных (например, определяемые пользователем типы и индексы с помощью определяемых пользователем функций) от кода, который не имеет таких сохраненных зависимостей данных. Дополнительные сведения см. в разделе "Реализация сборок и ALTER ASSEMBLY" (Transact-SQL).
Если для части управляемого кода требуется более высокое разрешение, лучше разделить этот код на отдельную сборку от кода, которая не требует более высокого разрешения.
Управление безопасностью сборок
Можно управлять доступом сборки к ресурсам, защищенным системой безопасности доступа к коду платформы .NET, когда она выполняет управляемый код. Для этого необходимо указать один из трех наборов разрешений при создании или изменении сборки: SAFE, EXTERNAL_ACCESS или UNSAFE.
БЕЗОПАСНЫЙ
SAFE — это набор разрешений по умолчанию, и он является самым строгим. Код, выполняемый сборкой с разрешениями SAFE, не может получить доступ к ресурсам внешней системы, таким как файлы, сети, переменные среды или реестр. Безопасный код может получить доступ к данным из локальных баз данных SQL Server или выполнять вычисления и бизнес-логику, не связанные с доступом к ресурсам за пределами локальных баз данных.
Большинство сборок выполняют задачи вычислений и управления данными без доступа к ресурсам за пределами SQL Server. Поэтому мы рекомендуем SAFE в качестве набора разрешений сборки.
EXTERNAL_ACCESS
EXTERNAL_ACCESS позволяет сборкам получать доступ к определенным внешним ресурсам системы, таким как файлы, сети, веб-службы, переменные среды и реестр. Только имена входа SQL Server с разрешениями EXTERNAL ACCESS могут создавать EXTERNAL_ACCESS сборки.
Сборки SAFE и EXTERNAL_ACCESS могут содержать только код, который является проверяемо типобезопасной. Это означает, что данные сборки могут получать доступ к классам только через правильно определенные точки входа, доступные для определения типа. Поэтому они не могут произвольно получить доступ к буферам памяти, не принадлежащим коду. Кроме того, они не могут выполнять операции, которые могут негативно повлиять на надежность процесса SQL Server.
ОПАСНЫЙ
UNSAFE предоставляет сборкам неограниченный доступ к ресурсам как внутри, так и за пределами SQL Server. Код, выполняющийся из сборки UNSAFE, может вызывать неуправляемый код.
Кроме того, указание UNSAFE позволяет коду в сборке выполнять операции, которые считаются небезопасными для средства проверки CLR. Эти операции могут получить доступ к буферам памяти в пространстве обработки SQL Server неконтролируемым образом. Сборки UNSAFE также могут подорвать систему безопасности SQL Server или среды CLR. Разрешения UNSAFE должны предоставляться только высоконадежным сборкам опытным разработчикам или администраторам. Только члены предопределенной роли сервера sysadmin могут создавать сборки UNSAFE.
Ограничения на сборки
SQL Server помещает определенные ограничения в управляемый код в сборки, чтобы убедиться, что они могут работать надежно и масштабируемо. Это означает, что определенные операции, которые могут компрометации надежности сервера, не допускаются в сборках SAFE и EXTERNAL_ACCESS.
Запрещенные настраиваемые атрибуты
Сборки не могут быть помечены следующими настраиваемыми атрибутами:
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
Кроме того, сборки SAFE и EXTERNAL_ACCESS не могут быть помечены следующими настраиваемыми атрибутами:
System.Security.SuppressUnmanagedCodeSecurityAttribute
System.Security.UnverifiableCodeAttribute
Неразрешенные API-интерфейсы платформы .NET Framework
Любой API Microsoft .NET Framework, помеченный одним из запрещенных hostProtectionAttributes , не может вызываться из сборок SAFE и EXTERNAL_ACCESS.
eSelfAffectingProcessMgmt
eSelfAffectingThreading
eSynchronization
eSharedState
eExternalProcessMgmt
eExternalThreading
eSecurityInfrastructure
eMayLeakOnAbort
eUI
Поддерживаемые сборки .NET Framework
Любая сборка, на которую ссылается пользовательская сборка, должна быть загружена в SQL Server с помощью CREATE ASSEMBLY. Следующие сборки .NET Framework уже загружаются в SQL Server и, следовательно, можно ссылаться на пользовательские сборки без использования 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